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INTRODUCTION  AND  SUMMARY 


The  Digital  Avionics  Information  System  (DAIS)  represents  a  signifi¬ 
cant  advance  in  the  technology  of  avionics  systems  architecture.  DAIS  is  a 
total  systems  concept,  exploiting  standardization,  modularity,  and  application- 
independent  executive  software  to  provide  a  system  architecture  adaptable  to 
many  aircraft,  missions,  and  avionics  configurations  and  fully  capable  of 
accommodating  new  advances  in  technology.  The  DAIS  architecture  results  in 
improved  reliability  and  availability  of  avionics  systems  while  at  the  same 
time  reducing  life  cycle  costs. 

Under  the  total  systems  concept,  DAIS  elements  are  not  dedicated  to 
any  one  avionics  function.  Rather,  the  elements  are  used  to  perform  the  pro¬ 
cessing  and  integrate  the  functions  associated  with  the  avionic  sensors  and 
subsystems  employed  for  a  particular  aircraft/configuration/mission.  This  is 
achieved  in  part  by  the  use  of  AN/AYK-15A  general  purpose  digital  processors 
conforming  to  MIL-STD-1750A.  The  processors  communicate  with  each  other  and 
other  system  elements  (e.g.  C&D  subsystem)  via  a  MIL-STD- 1 553B  dual  redundant 
multiplex  data  bus.  Centralized  system  single  point  control  is  performed  by  a 
processor-resident  software  executive.  Application  Software  is  structured  to 
provide  modularity,  reliability,  and  transferability.  Both  executive  and 
application  software  are  implemented  primarily  in  a  MIL-STD-1589B  JOVIAL  J73 
higher  order  language.  The  software  modularity  is  enforced  and  enhanced  by  a 
standard  executi ve-to-appl ications  software  interface. 

The  basic  elements  of  the  DAIS  architecture  which  can  be  reconfigured 
for  various  avionics  applications  are  called  DAIS  core  elements  (or  building 
blocks).  The  core  elements  consist  of  the  DAIS  processors,  DAIS  multiplex,  DAIS 
Mission  Software,  and  DAIS  Controls  and  Displays.  Additional  elements  are  the 
support  software  elements,  namely  the  JOVIAL  compiler,  the  assembler/1  inker , 
and  the  Partitioning,  Analyzing,  and  Linkage  Editing  Facility  (PALEFAC).  The 
core  elements,  along  with  support  hardware  and  software  were  integrated  into  a 
hot  bench  support  facility  also  known  as  the  Integrated  Test  Bed  (ITB).  A 
postulated  1980's  avionics  mission  was  flown  using  real-time,  pilot-in-the-loop 
simulations  to  demonstrate  the  DAIS  architecture  and  concepts.  The  subject  of 
this  report  is  the  description  of  the  functional  elements  and  operational 
characteristics  of  the  final  configuration  of  the  DAIS  ITB. 

The  final  ITB  configuration  is  the  result  of  developments  performed 
in  the  period  covered  by  this  report.  The  baseline  for  that  development  was 
the  DAIS  ITB  as  successfully  demonstrated  in  September  1978  and  documented  in 
AFAL-TR-79-1027 .  The  substance  of  the  development  was  the  incorporation  of  a 
number  of  system  improvements,  the  integration  of  second  generation  core  element 
hardware  and  the  conversion  to  the  newly  adopted  military  standards:  MIL-STD- 
1553B  (Multiplex),  MIL-STD-1750A  (Instruction  Set  Architecture),  and  M1L-STD- 
1589B  (Higher  Order  Language).  The  effort  included  the  upgrade  of  all  system 
level  specifications  to  completely  and  accurately  reflect  the  current  system 
implementation. 

This  report  presents  a  review  of  the  DAIS  architecture  with  a  section 
on  each  of  the  core  elements.  A  section  on  other  key  elements  and  each  of  the 
non-real -time  support  software  elements  is  also  included.  System  operation  is 
described  in  detail,  both  normal  operation  and  exception  management.  Principle 
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features  of  the  architecture  are  discussed  and  the  support  facility  is  des¬ 
cribed.  A  separate  discussion  of  the  software  and  hardware  conversion  efforts 
and  integration  and  testing  sequences  is  presented.  The  demonstration  mission 
scenarios  are  reviewed  and  project  management  and  control  procedures  are 
discussed.  Support  provided  to  other  Air  Force  programs  is  identified  and  a 
final  set  of  conclusions  and  recommendations  is  presented. 

Overall,  this  report  presents  and  describes  in  detail  an  avionic 
system  architecture  compliant  with  the  most  recent  military  standards,  already 
implemented  and  demonstrated,  which  is  easily  adaptable  to  many  aircraft  and 
missions. 
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2.0 


BACKGROUND 


The  Digital  Avionics  Information  System  (DAIS)  has  been  under 
development  by  the  Air  Force  since  1973.  Air  Force  avionics  systems  in 
existence  in  the  early  1970' s  were  largely  analog  systems  interconnected  by 
dedicated  wiring  harnesses.  In  addition  to  the  weight  penalty,  these  were 
difficult  to  maintain,  difficult  to  modify  in  response  to  new  threat  environ¬ 
ments,  and  difficult  to  upgrade  to  accommodate  new  technology.  The  initial 
thrust  of  DAIS  was  to  investigate  the  use  of  general  purpose  digital  computers 
for  avionics  processing  and  of  multiplexing  techniques  for  data  interchange. 

In  addition  to  these  two  specific  areas  of  technology,  DAIS  also  addressed  the 
larger  problem  of  providing  a  system  architecture  which  could  adapt  available 
avionics  subsystems  and  sensors  to  a  common,  modularly  expandable  avionics  core. 

The  lack  of  commonality  and  compatibility  was  an  area  of  major  con¬ 
cern.  The  classical  approach  to  avionics  provided  a  system  unique  to  each 
particular  aircraft.  Avionics  systems  tended  to  be  snapshots  of  technology 
available  at  the  time  of  development  with  little  or  nor  relationship  to  previous 
work.  The  result  is  that  aircraft  which  are  part  of  the  operational  fleet  at 
a  given  time  have  neither  commonality  of  hardware  or  software,  nor  any  sort  of 
compatibility.  The  effects  are  felt  in  costs  and  reliability.  Additional 
front-end  design  costs  are  incurred  and  a  less  mature  product  (hardware  and  soft¬ 
ware)  is  obtained  on  each  new  development  or  upgrade/retrofit  effort. 

Even  more  serious,  from  an  operational  viewpoint,  is  the  limited 
adaptability  of  point-designed  avionic  systems  to  changing  threat  environments 
or  expanded  mission  roles  for  the  weapon  system.  Past  experience  has  shown 
that  the  airframe  lifetime  is  significantly  longer  than  the  useful  (in  the 
sense  of  operational  capability)  lifetime  of  the  avionics.  Hence,  a  typical 
weapon  system  is  modified  many  times  during  the  life  of  the  airframe.  The 
Digital  Avionics  Information  System  (DAIS)  was  conceived  as  a  means  of  avoiding 
the  problems  inherent  in  the  classical  avionics  approach.  DAIS  considered  the 
avionics  job  as  a  hybrid  of  process  control  and  information  management  functions 
and  provided  a  system  architecture  independent  of  a  particular  airframe  and,  to 
a  large  extent,  of  the  technology  used  to  implement  the  system.  An  important 
aspect  of  the  DAIS  concept  is  that  it  views  the  avionics  as  a  whole  and  not  as 
a  collection  of  previously  defined  systems. 

By  using  this  approach,  common  functions  of  the  avionics  system  were 
identified  which  are  required  by  each  of  the  mission  functions.  This  resulted 
in  an  integrated  avionics  system  which  accomplishes  all  of  the  required  mission 
functions  but  is  partitioned  along  the  lines  of  processing  hardware,  software, 
information  transfer,  and  display  and  control.  A  new  partitioning  of  the 
avionics  system  was  defined  so  that  the  mission  functions  could  be  mapped  onto 
that  partitioning.  The  next  step  was  to  apply  some  constraints  to  the  evolving 
system  architecture.  For  reasons  of  cost,  maximum  utilization  of  common  hard¬ 
ware  was  desired.  In  order  to  enhance  redundancy  and  error  management  and 
recovery,  maximum  sharing  of  information  and  maximum  use  of  shared  resources 
were  desired.  This  was  based  on  the  premise  that  if  the  necessary  information 
is  available  system-wide,  the  system  can  re-orient  the  task  of  selected  resources 
to  accomplish  critical  mission  functions  when  primary  resources  have  failed. 

One  of  the  few  performance  improvement  constraints  was  to  provide  a  better  method 
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of  interfacing  to  the  pilot.  The  classical  system  forces  the  pilot  to  process 
large  amounts  of  raw  data  as  well  as  make  decisions.  The  DAIS  approach  was 
to  produce  data  for  the  pilot  and  aid  his  decision  process,  thereby  reducing 
pilot  workload.  The  final  constraint  was  to  provide  an  open-ended  system 
capability.  The  architecture  chosen  should  be  capable  of  handling  tasks 
larger  than  any  anticipated  today  and  should  not  depend  upon  today's  technology. 
The  system  should  be  able  to  expand  or  change  by  adding  or  modifying  resources 
without  affecting  the  architecture. 

The  topology  chosen  for  DAIS  was  that  of  a  distributed  system.  This 
allowed  physically  distributing  the  resources  to  enhance  survivability  and 
provided  a  means  for  expanding  system  capability  without  regard  to  physical 
placement  of  the  resources.  The  architecture  chosen  for  DAIS  s  a  hierarchical 
system  structure  operating  under  centralized  control.  To  the  "user",  therefore, 
DAIS  appears  as  a  centralized  system.  The  implementation  of  DAIS  required  the 
development  of  certain  building  blocks  to  achieve  the  design  goals.  These 
building  blocks  are  called  the  DAIS  core  elements  and  consist  generically  of 
processors,  multiplex  equipment,  control  and  display  subsystem  and  the  software 
associated  with  the  flight  processors. 

AFWAL  initiated  the  DAIS  program  in  1973  with  two  separate  contracts 
to  Texas  Instruments  ( F33615- 73-C- 1156)  and  General  Dynamics  ( F 33615-7 3-C-1244> 
to  define  and  provide  the  guidelines  for  the  design  of  the  DAIS  system,  follow¬ 
ing  these  studies,  contracts  to  The  Boeing  Company  (F33615-74-C-1108)  and  Texas 
Instruments  ( F3361 5-74-C- 1023 )  were  let  to  provide  the  initial  hardware  and 
software  specifications  for  the  DAIS  core  elements,  and  initial  system  designs 
for  DAIS. 


Subsequent  to  these  studies,  AFWAL  let  contracts  to  design  and  develop 
the  core  elements  as  shown  below: 


Multiplex  Equipment 
Processor 
Mission  Software 
Controls  &  Displays 


IBM 

Westinghouse 

Intermetrics 

Hughes 


Also,  AFWAL  let  a  System  Integration  and  Test  Coordination  (SITC)  contract  with 
TRW  Defense  and  Space  Systems  to  support  AFWAL  in  combining  these  core  elements, 
along  with  support  hardware  and  software,  into  an  integrated  test  bed  (ITB)  or 
"hot  bench". 


The  initial  part  of  the  SITC  effort  was  the  development  and  demonstra¬ 
tion  of  the  Hardware  Architecture  Simulation,  a  DAIS  prototype,  to  investigate 
and  verify  the  DAIS  architecture.  This  effort  provided  confirmation  of  the 
feasibility  of  the  DAIS  architecture  and  supplied  useful  inputs  to  the  concurrent 
development  of  fhe  core  elements.  As  the  core  elements  were  delivered,  they 
were  tested  and  integrated  into  the  hot  bench  facility.  This  effort  culminated 
in  the  successful  demonstration  of  a  Close  Air  Support  mission  in  September  1978. 

AFWAL  awarded  follow-on  contracts  to  TRW  ( F 33625-78-R- 1 502 )  for 
continued  System  Integration  and  Test  Coordination  (SITC)  and  to  Intermetrics 
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(F33615-78-R-1542)  for  Mission  Software  Enhancements  (MSE).  Second  generation 
core  element  hardware  was  procured  as  shown  below: 

Processors  Westinghouse 

(dual  procurement)  Sperry-Univac 

Multiplex  Equipment  IBM 

In  parallel  and  interactive  with  these  efforts,  the  Air  Force  was 
pursuing  the  finalization  of  revisions  to  the  key  avionics  military  standards. 
These  were  approved  as  follows: 

MIL-STD-1553B  September  1978 

(Multiplex) 

MIL-STD-1750A  July  1980 

(processor  instruction 
set  architecture) 

MIL-STD-1589B  June  1980 

(high  order  language) 

AFWAL  anticipated  the  importance  of  DAIS  demonstrating  an  implementa¬ 
tion  of  these  standards  and  extended  the  SITC  contract  to  accomplish  the 
necessary  conversions.  The  integration  of  the  second  generation  core  elements 
and  the  conversion  to  the  new  MIL-STD's  was  accomplished  and  a  formal  demonstra¬ 
tion  of  the  DAIS  ITB  was  performed  in  March  1981.  The  final  configuration  of 
the  ITB  and  efforts  leading  to  it  are  the  subjects  of  this  report. 
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3.0 


DAIS  SYSTEM  ARCHITECTURE 


Historically,  avionic  systems  have  been  established  along  semi- 
autonomous  functional  areas  such  as  navigation,  weapon  delivery,  stores 
management,  flight  control,  communications,  etc.  Each  of  these  functional 
areas  would  have  an  analog  or  digital  system  with  its  own  processing, 
information  transfer,  control  inputs,  and  display  set.  There  would  be  an 
interface  between  functional  areas  only  as  necessary  for  interaction  pur¬ 
poses,  usually  a  one-of-a-kind,  non-standard  interface.  The  DAIS  concept  is 
that  the  processing,  information  transfer,  control  and  display  functions  be 
common  and  service  all  the  previously  described  functional  areas  on  an 
integrated  basis. 

These  basic  functions  are  implemented  via  the  core  elements  which 
are  aircraft  and  mission  independent.  The  specific  avionics  capabilities 
are  then  achieved  by  selecting  the  sensors,  weapons,  and  other  subsystems 
desired  and  installing  the  appropriate  application  software  to  control  and 
process  the  avionics  data.  This  functional  architecture  is  represented  in 
Figure  1. 


The  purpose  of  the  DAIS  concept  is  to  reduce  the  proliferation  and 
non-standardization  of  aircraft  avionics  and  permit  the  Air  Force  to  assume 
the  initiative  in  the  specification  of  standard  avionic  systems  and  interfaces 
for  future  Air  Force  System  acquisitions.  This  approach  of  isolating  the  core 
elements,  and  separately  developing  and  verifying  them  should  also  aid  Air 
Force  suppliers  by  permitting  them  to  concentrate  on  the  specific  avionics 
problem  by  viewing  the  core  elements  as  a  service  facility  interconnecting  the 
application  software  with  the  sensor/subsystem  hardware.  The  general  objectives 
of  the  DAIS  architectural  design  are  listed  in  Table  1  along  with  the  design 
considerations  or  attributes  to  help  satisfy  the  objectives.  These  attributes, 
such  as  standardization,  redundancy,  modularity,  on-board  test,  etc.,  have  been 
designed  into  the  system  at  the  start  as  opposed  to  incorporation  at  a  later 
stage. 


3. 1  System  Configuration 

The  DAIS  configuration  is  shown  in  Figure  2.  The  MIL-STD-1553B 
data  bus  is  the  central  element  of  the  configuration;  it  provides  the  commun¬ 
ication  link  between  the  DAIS  processors,  Controls  and  Displays,  and  aircraft 
subsystems.  The  basic  core  elements  or  building  blocks  of  DAIS  are  the  DAIS 
multiplex  system  (dual  bus  and  remote  terminals)  DAIS  processor/BCMs ,  DAIS 
Mission  Software,  and  DAIS  Controls  and  Displays. 

The  AN/AYK-15A  processors  include  the  bus  interface/controller 
function  and  normally  reference  is  made  to  a  "Processor/BCM"  as  a  functional 
unit.  The  Remote  Terminals  (RT's)  receive  various  analog,  digital,  and  dis¬ 
crete  signals  from  the  sensors/subsystems  and  format  these  for  bus  transmission. 
The  RT  is  designed  to  accommodate  various  types  of  interface  modules  to  provide 
the  proper  electrical  interface  with  different  sensors.  It  is  programmable  to 
permit  mapping  of  the  data  between  the  data  bus  and  the  sensors  as  required  for 
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FUNCTIONAL  ARCHITECTURE 


the  specific  avionic  system  configuration.  Sensors,  control  and  display 
equipment,  or  other  subsystems,  may  interface  directly  to  the  bus,  or  may 
interface  via  the  Interface  Modules  of  a  Remote  Terminal  CRT).  This  ‘legi¬ 
bility  is  provided  within  the  communications  protocol  of  the  MIL-STD- lbS3t> 
multiplex  bus. 

In  normal  system  operation,  one  processor/BCM  is  designated  as 
master  and  is  in  control  of  the  system.  All  bus  commands  are  issued  by  this 
unit  under  the  direction  of  the  Master  Executive  software  resident  in  the 
processor  memory.  The  remaining  processor/BCMs  are  designated  as  remotes  and 
contain  mission  application  software  appropriate  for  the  configuration.  All 
processors  also  contain  software  known  as  the  Local  Executive  providing  basic 
real-time  task  management  and  utility  functions. 

The  Processor  Control  Panel  (PCP)  is  interfaced  to  the  multiplex  bus 
via  an  RT  and  provides  the  pilot  control  over  what  processors  are  active  in  a 
configuration.  The  system  mass  memory  is  actually  a  simulation  of  a  bubble 
memory  device  with  an  embedded  bus  interface.  Two  independent,  fully  redundant 
RTs  are  used  to  interface  the  C&D  system  to  assure  availability  of  this  critical 
pilot  interface.  Other  RTs/Subsystems  are  added  to  the  configuration  as  required 
for  a  particular  mission  demonstration.  The  RTs  may  also  be  simulated  in  the 
Universal  Remote  Terminal  (URT). 

it  should  be  clear  that  while  this  specific  configuration  was 
implemented  in  the  ITB,  the  DAIS  architecture  is  applicable  to  a  wide  range 
of  configurations.  F'or  illustration,  a  generalized  DAIS  configuration  is 
shown  in  Figure  3.  The  main  point  is  that  DAIS  provides  a  set  of  application- 

independent  core  elements.  For  a  specific  aircraft  application,  the  system 
designer  is  at  liberty  to  configure  these  building  blocks  to  the  specific 
hardware  configuration  required.  Tne  software  can  also  be  partitioned  based 
upon  avionic  subsystems  and  mission  requirements  such  as  reliability  and 
availability.  The  support  software,  J73  Compiler  and  PALEFAC,  provide  the 
system  designer  and  application  programmer  the  tools  to  develop,  test,  and 
partition  the  appl ication  software  and  automatically  generate  the  executive 
tables  for  the  specific  aircraft  configuration. 

The  number  of  processors  can  be  reduced  or  enlarged  depending  upon 
the  avionics  and  mission  requirements.  Application-independent  executive 
software  makes  the  DAIS  architecture  flexible  and  adaptable.  It  can  be 
applied  to  a  broad  class  of  appl  ications,  and  mission-to-mission  changes  in  a 
particular  aircraft  are  also  easily  accommodated.  Sensors,  weapons,  and  other 
subsystems  are  selected  as  required  for  the  particular  mission.  Application 
modules  of  the  software  are  selected  or  developed  as  required  by  the  sub¬ 
systems.  This  basic  DAIS  architecture  reduces  unnecessary  development  duplica¬ 
tion  of  similar  tasks  every  time  new  systems  are  developed. 

3.2  DAIS  Core  Elements 

The  basic  elements  of  the  DAIS  architecture,  which  are  independent 
of  the  aircraft  and  mission, are  known  as  the  core  elements  and  consist  of: 

DAIS  Multiplex  (dual  bus  and  RTs) 

DAIS  Processor/BCI 

DAIS  Controls  and  Displays 

DAIS  Executive  Software 
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The  system  designer  must  detenu ir;e  the  nui.iber  of  proi essor/BCMs 
required,  but  otherwise  fully  defines  systen.  functionality  solely  with  t.  ;  l  i  - 
cations  software  ami  the  suite  of  avionics  sensors/subsyster  •_  conf  •' -lured. 

The  core  elements  are  described  in  the  following  sections. 

3.2.1  DAIS  Multiplex 

The  DAIS  multiplex  provides  a  channel  for  information  transfer  between 
the  elements  within  the  system.  It  consists  of  toe  Bus  Controller  Interface  Unit 
(BCIU)  or  integrated  processor/bus  controller  (AM/Aih- 15A) .  Remote  Terminal  units 
(RT),  and  the  multiplex  cable  assembly  (data  bus).  The  message  structure,  data 
format,  and  command- respond  protocol  is  as  defined  in  MlL-STD-15o3B.  The  messaae 
format  consists  of  three  types  of  operations  as  shown  in  Figure  4  with  word  for¬ 
mats  as  shown  in  Figure  5.  The  communications  protocol  is  a  time  division 
multiplex  (TDM),  command-response  approach  with  one  processor/BCIU  controlling 
the  bus  traffic  at  any  given  time.  Each  multiplex  cable  assembly  consists  of 
a  twisted,  shielded  wire  pair  and  bus  couplers. 

Message  protocol  is  the  sequence  of  the  bus  messages  required  to 
perform  system  and  bus  control  functions  (synchronous  and  asynchronous  opera¬ 
tions)  and  error  and  failure  management  operations.  A  set  of  system  control 
procedures  was  defined  to  describe  the  procedures  to  perform  these  operations 
as  summarized  in  paragraph  4.1.  The  overall  message  sequencing  is  shown  in 
Figure  6. 


a.  Bus  Controller  Interface  Unit  (BCIU).  The  BCIU  provides  the 
interface,  control,  and  data  transfer  functions  between  a  processor  and  two 
data  buses.  The  BCIU  operates  under  control  of  the  Executive  software  in 
either  a  remote  mode  or  master  mode. 

In  the  remote  mode,  the  BCIU  provides  the  transfer  of  data  to  and 
from  the  processor  based  upon  commands  received  from  either  of  the  data  buses. 

It  provides  the  status  reply  on  the  appropriate  data  bus,  performs  special 
internal  operations,  and  presents  interrupts  to  the  processor  for  a  few  speci¬ 
fied  conditions. 

In  the  master  mode,  the  BCIU  constructs  and  issues  the  bus  commands 
based  on  a  two-word  instruction  fetched  from  the  processor  memory.  These 
instruction  words  contain  not  only  transmi ttinq-recri ving  terminal  addresses, 
subaddresses,  and  word  count  fields,  but  also  the  fields  to  dictate  bus  selec¬ 
tion,  automatic  retry  options,  and  BCIU  internal  operation  codes.  The  BCIU 
sequentially  interprets  each  instruction  pair  to  determine  the  action  required. 
Depending  on  the  op-code  contained  in  the  instruction  paii ,  the  BCIU  initiates 
a  bus  operation,  performs  a  no-op,  or  performs  a  link  operation.  If  a  bus 
operation  is  indicated,  the  BCIU  controls  the  message  transmission  on  the  data 
bus.  It  accesses  the  next  sequential  instruction  pair  when  the  present  operation 
is  completed  successfully.  If  a  no-op  is  indicated,  the  BCIU  accesses  the  next 
requested  instruction  pair.  If  a  link  operation  is  indicated,  the  BCIU  performs 
no  bus  operation,  but  uses  the  second  word  of  the  instruction  as  the  address  of 
the  next  instruction  pair. 
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FIGURE  4.  MIL-STD-1553B  MESSAGE  FORMATS 


FIG  I  JR  F  5.  MIL-STD-1553B  WORD  FORMATS 


FIGURE  6.  MIL-STD-1553B  MESSAGE  SEQUENCING 


Figure  7  identifies  the  major  components  that  comprise  a  BCIU. 

Each  Multiplex  Terminal  Unit  (MTU)  provides  the  interface  function  to  one- 
data  bus.  The  Processor  Interface  Module  (PIM)  provides  the  interface 
function  to  the  processor.  The  chancing  of  processor  types  is  accommodated 
by  a  re-design  of  only  the  PIM.  The  Bus  Control  Module  (BCM)  provides  the 
timing,  control,  instruction  decoding,  and  data  transfer  routing  required 
to  implement  the  various  operations.  The  BCIU  also  performs  mode  code  opera¬ 
tions  to  obtain  status  or  built-in-test  information  for  error  and  failure 
analysis  or  to  perform  special  mode  operations  as  defined  in  paragraph  4. 1.2.2. 

b.  Bus  Control  Interface  Module  (BCI).  The  BCI  is  embedded  in  the 
AN/AYK-15A  processor  and  operates  in  either  of  two  modes:  master  or  remote. 

The  BCI  performs  the  same  duties  as  the  BCIU  but  provides  enhanced  status  word 
interpretation  and  interrupt  code  generation.  Figure  8  shows  the  major  com¬ 
ponents  of  the  AN/AYK-15A  processor/bus  controller, 

c.  Remote  Terminal  (RT).  The  Remote  Terminal  provides  the  interface 
between  the  subsystems  and  the  two  data  buses.  The  RT  transfers  data  in  both 
directions  between  the  multiplex  bus  and  subsystem  via  the  Interface  Modules. 

It  receives  these  commands  from  either  of  Che  data  buses  and  provides  the 
status  reply  on  the  appropriate  bus.  The  RT  performs  special  mode  command 
operations  upon  receipt  of  a  mode  command. 

The  RT  is  modular  and  programmable.  This  allows  flexible  partition¬ 
ing  of  the  data  messages  to  the  appropriate  subsystems/sensors  and  signal 
conditioning  required  by  different  numbers  and  mixes  of  subsystem  and  signals. 
The  RT  is  composed  of  Multiplex  Terminal  Unit  (MTU),  Timing  and  Control  Unit 
(TCU),  and  Interface  Modules  (IM)  as  shown  in  Figure  9.  The  Multiplex  Terminal 
Unit  (MTU)  interfaces  to  the  data  bus.  It  transmits  and  receives  information 
between  the  data  bus  and  the  Timing  and  Control  Unit  (TCU)  under  control  of  the 
TCU.  The  RT  is  dual  redundant  with  respect  to  the  MTU,  TCU,  and  power  supplies. 

The  Timing  and  Control  Unit  (TCU)  performs  all  of  the  timing,  control, 
buffering,  decoding,  and  checking  required  to  receive  or  transmit  information 
on  the  data  bus.  It  transfers  that  information  as  outputs  or  inputs  from  the 
RT  via  the  Interface  Modules  (IM).  The  TCU  contains  a  Drogrammable  device  which 
controls  the  mapping  of  each  data  word  in  each  message  to  the  proper  subsystem 
interface,  i.e.,  the  specific  IM  slot  in  the  RT  and  channel  on  that  IM.  The 
interface  between  the  TCU  and  IM  is  standardized  and  contains  the  signals  re¬ 
quired  to  allow  the  TCU  to  select  the  individual  nodules.  Therefore,  all  IM 
slots  accept  all  IM  types. 

Each  RT  will  interface  with  different  numbers  and  mixes  of  subsystems/ 
sensors  signals  for  each  specific  system  configuration.  This  is  accomplished 
by  inserting  the  proper  number  and  type  of  interface  modules  into  the  IM  slots 
in  the  RT  housing  and  by  programming  the  ROM  in  the  TCU.  Table  2  lists  the 
typical  type  of  RT  Interface  Modules  provided  to  interface  with  the  subsystems. 
If  required,  a  special  interface  module  can  be  designed  to  interface  with  any 
existing  subsystem. 

The  MTU  and  TCU  functions  of  the  RT  can  be  embedded  in  a  sensor  or 
subsystem  so  that  the  interface  of  the  sensor  or  subsystem  is  directly  with 
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Central  Processing  Unit  PIO  -  Parallel  Input/Output 

Direct  Memory  Access  PMI  -  Performance  Monitoring  Interface 

Extended  Arithmetic  Unit  ROM  -  Read  Only  Memory 


FIGURE  8.  DAIS  PROCESSOR/BUS  CONTROLLER  { AN/AVK-15A) 


HOUSING 


FIGURE  9.  REMOTE  TERMINAL  UNIT 


TAtfLE  2.  RT  INTERFACE  MODULES 


the  multiplex  data  bus.  Functionally,  the  embedded  RT  responds  to  commands 
received  on  either  data  buses  in  the  same  way  as  an  RT. 

3.2.2  OAIS  Processors 


The  AN/AYK-15  OAIS  processors  provide  computational  ,  control  , 
memory,  and  input/output  capabilities.  The  DAIS  processors  are  distributed 
in  the  architecture  and  are  interconnected  through  the  DAIS  multiplex  system. 
In  this  architecture,  the  processors  address  only  their  own  memory  units. 

The  DAIS  processors  include  the  following  features: 

•  Central  Processor  Unit  (CPU) 

0  16  general  registers 

t  Extensive  instruction  repertoire 

0  379K  operations  per  second  throughput  based  upon 
a  specified  benchmark  program 

0  Floating  point  capability 

0  Direct,  indirect,  immediate  and  index  addressing 
modes 

0  Programmable  interval  timers 
0  Vectored  interrupts 
0  Memory 

0  Expandable  random  access  memory  to  65K  words 
(16-bit  words),  in  16K  word  memory  modules 

0  Memory  parity  and  write  protect  features 

0  Input  and  Output 

0  Discretes 

0  Program  controlled 

0  Direct  Memory  Access  (DMA) 

0  External  interrupts 

The  AN/AYK-15A  integrated  DAIS  processor/bus  controller  combines  the 
processor  and  BCIU  functions  into  an  integrated  unit  and  incorporates  the  MIL- 
STD-1750  instruction  set.  Figure  8  describes  the  AN/AYK-15A.  This  integrated 
DAIS  processor/bus  controller  includes  the  following  features: 
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•  Processor 

•  16  general  registers 

•  Extensive  instruction  repertoire  as  specified  in 
M I L- STD- 1750 

•  400K  operations  per  second  throughput  based  upon 
specified  benchmark  program 

•  Floating  point  capability 

•  Direct,  indirect,  immediate,  base  relative,  IC 
relative,  and  index  addressing  modps 

•  Progra/mable  interval  timers 

•  Vectored  interrupts 

•  Memory 

•  Expandable  random  access  memory  to  65K  words 
(16  bits  per  word),  in  16K  word  memory  modules 

•  Memory  parity  and  write  protect  features 

•  Input  and  Output 

•  Discretes 

•  Program  controlled 

•  Direct  memory  access 

•  External,  encoded  interrupts 
t  Multiplex  data  bus 

•  Bus  controller 

3.2.3  DAIS  Controls  and  Displays 

The  DAIS  Controls  and  Displays  (C&D)  provide  the  interface  between 
the  pilot  and  the  various  avionics.  The  C&D  consists  of  a  set  of  shared 
multipurpose  data  entry  devices,  control  devices,  and  display  devices.  The 
C&D  concept  is  based  upon  an  integrated  set  of  common  and  shared  devices  which 
can  be  used  for  most  of  the  avionic  functions.  Thus,  the  DAIS  Controls  and 
Displays  concept  embodies  the  following  features: 

t  Flexibility  to  accommodate  changes  in  avionic  functions 
and  moding  as  a  result  of  new  sensors/subsystems  or 
mission  changes  without  requiring  a  physical  change  in 
the  control  and  display  devices. 


•  Efficient  design  for  centralized  system  management  by 
the  pilot  as  required  for  the  system  application. 


•  Redundancy  if  required  for  specific  system  application 
(e.q.  CRT's  serve  as  backup  to  each  other,  redundant 
display  generators)  for  backup  of  mission-critical 
functions. 

•  Provisions  for  mode  control  and  command  data  from  data 
entry  devices  and  to  display  devices  to  be  transmitted 
and  received  over  the  multiplex  bus  to  or  from  mission 
software. 

The  set  of  Control  and  Display  equipment  developed  for  the  DAIS  demonstration 
is  representative  of  what  one  would  utilize  in  the  DAIS  architecture.  An 
example  of  the  Controls  and  Displays  subsystem  configuration  is  shown  in 
Figure  10.  The  units  or  building  blocks  of  the  DAIS  controls  and  displays 
include  the  following. 

a.  Modular  Programmable  Display  Generator  (MPD6).  The  MPDG  is  a 
programmable  graphic  display  generator.  It  is  capable  of  being  programmed 

to  generate  graphics  composed  of  predefined  symbols,  line  segments,  and  alpha¬ 
numeric  symbols.  The  MPDG  generates  symbols  for  presentation  on  both  raster 
and  stroke  written  display  devices.  The  MPDG  generates  the  display  data  for 
up  to  four  raster  display  devices  via  the  Display  Switch/Memory  Unit  (DS/MU) 
which  contains  the  refresh  memory  for  the  raster  displays.  The  MPDG  also 
generates  stroke  (x  and  y  deflection  signals,  and  blank/unblank  signals)  for 
one  stroke  display. 

The  MPDG  generates  various  forms  of  symbology  including  geographic 
map  symbols,  overlay  symbols,  tactical  horizontal  and  vertical  situation 
data,  and  flight  situation  and  director  symbols  as  programed  in  the  C&D  sub¬ 
system  application  software.  This  application  software  executes  on  the 
programmable  processor  in  the  MPDG. 

b.  C&D  Subsystem  Appl ication  Software.  The  C&D  subsystem  applica¬ 
tion  software  consists  of  the  routines  and  display  lists  for  the  display 
generator  in  the  MPDG.  This  software  generates  the  display  symbology,  text 
formats  and  pages,  map  data,  etc.,  required  for  a  specific  avionics  system 
application.  Mode  control  and  data  messages  received  from  mission  software 
via  the  multiplex  system  controls  the  display  modes,  display  assignments, 
text  displays,  and  variable  symbology.  The  application  software  is  commanded 
by  mission  software.  It  performs  the  loading  of  the  MPDG  programs,  text  pages, 
and  map  data  from  the  C&D  Mass  Memory  Unit  (MMU). 

The  specific  application  software  was  developed  using  an  MPDG 
assembler  hosted  on  a  DECsystem-10.  The  source  language  consists  of  the  MPDG 
microprocessor  instructions,  display  generator  command  formats,  and  assembler 
directives. 

c.  Display  Switch/Memory  Unit  (DS/MU).  The  DS/MU  is  used  in  con¬ 
junction  with  one  or  two  MPDGs  to  drive  tne  raster  display  devices.  The 
DS/MU  accepts  digital  data  from  one  or  two  MPDGs,  stores  the  data  in  up  to 
six  refresh  memories,  and  sends  the  data  to  up  to  four  raster  displays  (525- 
line  or  875-line  format). 
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iURE  10.  CONTROL  Ml)  DISPLAY 


The  raster  displays  are  displayed  alone  or  overlayed  with  sensor 
video.  The  DS/MU  provides  the  capability  to  route  signals  from  up  to  14 
sensor  or  weapon  video  sources  (e.g.  TV  sensor  -  525  line,  FL1R  sensor  - 
875  line,  weapon  station  sensors  -  525  line)  to  any  of  the  four  raster  dis¬ 
plays.  One  external  video  signal  is  routed  to  a  single  display  at  one  time. 

The  DS/MU  also  accepts  stroke-generated  signals  from  one  or  two 
MPDGs  and  routes  these  signals  to  one  of  the  two  stroke  displays.  Although 
the  DS/MU  is  a  serial  element  in  the  system,  it  is  designed  to  minimize  the 
probability  that  a  single  failure  will  cause  complete  loss  of  display 
capability. 

d.  Display  Devices.  The  display  devices  are  cathode-ray-tube  (CRT) 
displays  which  are  driven  by  the  MPDG  and  DSMU  as  described  above.  This  allows 
changes  or  additions  to  the  information  displayed  to  the  pilot  without  physical 
changes  to  or  movement  of  the  display  devices  in  the  cockpit.  The  CRT  display 
devices  consist  of  raster-written  and  stroke-written  devices  as  follows: 

•  Head-Up  Display  (HUD)  -  stroke-written 

•  Multiple  Purpose  Displays  (MPDs)  -  raster-written 

The  MPDs  can  be  used  for  Vertical  Situation  Display  (VSD),  Horizontal 
Situation  Display  (HSD)  and  Multi-Purpose  Displays  (MPDs)  as  required  by  the 
specific  avionics  systems  configuration.  All  the  MPDs  are  identical  except  for 
the  legends  on  the  display  selection  buttons.  The  Head-Up  Display  (HUD)  pre¬ 
sents  the  symbology  (e.g.  cues,  flight  information)  in  the  pilot's  forward 
field-of-view,  so  out-the-window  scenes  (e.g.  targets,  IPs,  etc.)  can  be  viewed. 

e.  Data  Entry  Devices.  The  data  entry  devices  provide  flexibility 
in  the  information  which  can  be  entered  by  the  pilot  to  control  and  manage  the 
specific  avionics  system  (mission  functions,  sensors,  and  subsystems).  The 
design  of  the  data  entry  devices  allows  changes  or  modifications  to  the 
avionics  functions  without  physical  changes  to  the  cockpit.  The  output  of  the 
data  entry  device  is  received  and  interpreted  by  Mission  Software  via  the 
multiplex  system.  Display  responses  to  the  device  are  generated  by  mission 
software  via  the  multiplex  system.  The  type  of  data  entry  devices  include  the 
following: 


1.  Integrated  Multifunction  Keyboard  (IMFK).  The  IMFK  consists  of 
a  programmable  alphanumeric  280  character  display,  seven  master  function  push¬ 
buttons,  and  ten  submode  select  pushbutton  switches,  five  on  either  side  of 
the  display.  The  IMFK  display  is  capable  of  displaying  ten  rows  of  characters 
divided  into  three  columns  (nine  characters  in  left  and  right  columns,  and 

ten  characters  in  center  column).  The  display  information  is  generated  by 
mission  software.  The  pushbuttons  generate  a  request  via  the  remote  terminal 
for  the  master  executive  to  asynchronously  service  and  transmit  the  data  to 
the  appropriate  processor.  Application  software  interprets  the  pushbutton 
or  switch  action  and  provides  the  appropriate  response. 

2.  Multifunction  Keyboard  (MFK).  The  MFK  consists  of  seven  master 
tunction  pushbuttons,  ten  submode  pushbutton  switches,  and  ten  indicator 
lights.  The  MFK  interfaces  with  mission  software  via  the  RT  in  the  same  wav 
as  the  IMFK.  It  can  be  utilized  for  specific  control  and  display  functions 
or  as  a  backup  for  the  IMFK. 
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3.  Da_ta_Entry  Keyboard  _{DEK) .  The  DE  Y  provides  the  pilot  w  t> 
means  of  entering  numeric  and  limited  alpha  data  into  mission  software  via 
the  multiplex  data  bus.  The  D'  K  stores  and  disnlays  up  to  fen  chard'  t*-rs. 

When  the  enter  key  is  depressed,  a  inquest  for  service  via  the  RT  is  ratio 
to  the  master  executive.  Upon  receiving  the  data.  Mission  Software  inter¬ 
prets  the  data  dependinq  upon  the  selected  submode  via  tire  IMP'  or  MFK. 

f.  Control  Devices.  The  Controls  <nd  Displays  subsystem  also 
provides  several  control  devices  as  follows: 

1.  Sensor  Control  Unit (SCU).  The  SCU  provides  fo>  selection  arid 
position  controT  of  a  Sj.nbol  or  sensor  (X  and  V  directions).  The  hand  con¬ 
troller  is  a  force  control  with  D-.  voltage  output  which  is  orope't  tonr  1  to 

the  force  in  the  X  and  Y  directions.  The  SCU  also  provides  tr’  iger  and  switch 
discrete  outputs.  These  outputs  are  transmitted  to  mission  software  via  the 
multiplex  data  bus;  mission  software  drives  the  ipironriatc  symbol  or  sensor 
based  upon  the  selected  mode.  The  SCU  al ,o  provides  a  contro1  k"cb  to  co'»t>  c 1 
cursor  brightness. 

2.  Armament  Panel  (AP).  The  armament,  panel  provides  switches  for 
weapon  armament  control  (bombing ,  fusing,  nun  firing,  and  jettison). 

3.  Master  Mode  Pane!  (MMP).  The  MMP  consists  of  fifteen  master 
mode  switches.  Each  has  an  indicator  light  and  HUD- related  switches  and  con¬ 
trols.  When  a  master  mode  switch  is  depressed,  <•  request  for  service  will  be 
made  to  the  master  executive.  Unon  receiving  the  data,  •  •■ission  software  intei  - 
prets  and  responds  to  the  selected  master  mode. 

The  interface  between  the  pilot  and  the  integrated  set  of  Controls 
and  Displays  is  dependent  upon  the  specific  avionic  mission  and  system  con¬ 
figuration.  The  system  designer  selects  the  set  of  integrated  Controls  and 
Displays  required  for  the  specific  avionic  system  and  cefines  the  pilot 
sequences  and  display  responses  requiied  to  control  and  mode  the  avionics 
system. 


The  interface  between  the  Mission  Software  and  the  C&D  application 
software  in  the  MPDG  is  also  mission-and  application-dependent.  This  inter¬ 
face  is  defined  by  the  data  bus  messages  from  Mission  Software  to  the  MPDG 
to  perform  the  following  functions: 

•  Load  the  MPDG 

•  Control  display  (VSD,  MPD,  HAD,  &  HUD)  assignment  - 

•  Control  display  modes 

•  Provide  data  to  drive  the  display  symbology,  e.g. 
elevation,  altitude,  heading,  etc. 

•  Provide  text  data 
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With  increased  avionic  and  mission  complexity,  the  role  of  the 
pilot  is  changing  to  that  of  a  total  system  manager.  Mission  Software  can 
perform  the  systems  management  function,  collecting  information  and  con¬ 
trolling  a  functionally  integrated  set  of  subsystems  and  sensors,  to  reduce 
the  pilot  workload.  Functions  such  as  subsystem  checkout  and  monitoring, 
data  computation  and  reduction,  routine  sequencing  within  mission  modes,  and 
mission  and  aircraft  data  storage  can  be  performed  by  the  mission  software 
with  minimum  pilot  intervention.  Operation  by  exception  can  be  designed 
into  the  system  control  and  operation. 

For  example,  the  pilot  can  use  the  integrated  Controls  and  Displays 
to  mode  the  avionics  system  throuqh  the  Mission  Software  applications  func¬ 
tions.  He  receives  display  information  about  the  mission  and  avionics 
system  operations  from  the  software.  The  control  devices  permit  the  pilot  to 
establish  the  operations  to  be  performed  by  the  software  functions.  The 
master  modes  set  the  display  devices  to  prescribed  formats  via  Mission  Soft¬ 
ware  and  the  MPDG.  The  pilot,  however,  can  override  these  normal  operations 
to  either  cause  alternate  modes  or  activate  operations  not  required  by  the 
selected  master  mode. 

Master  modes  are  defined  for  specific  phases  of  the  mission  where 
certain  normal  operations  are  active.  Upon  entering  a  new  master  mode,  some 
previous  operations  are  terminated  as  new  ones  are  activated.  Manual  modes 
previously  selected  by  the  pilot  can  be  retained  if  compatible  with  the  new 
master  mode.  If  the  new  master  mode  requires  a  system  that  has  been "deselected" 
using  the  manual  mode,  the  pilot  is  alerted  through  display  exception  messages. 
The  Master  Mode  Panel,  as  labeled  for  the  specific  mission  applications,  permits 
the  pilot  to  select  these  prescribed  master  modes.  Mission  software,  in  res¬ 
ponse  to  the  selected  master  mode,  will  command  the  C&D  application  software  to 
generate  formats  for  the  various  displays  (HUD,  VSD,  MPD,  etv,.).  The  pilot  can 
override  the  preprogrammed  mission  functions  through  the  IMFK-di splayed  pages 
and  side  keys  which  are  also  handled  by  mission  software.  The  pilot  will  also 
be  able  to  enter  information  into  Mission  Software  via  the  DEK.  For  the  DAIS 
demonstration,  a  representative  set  of  master  modes  and  mission  operational 
sequences  were  defined  and  implemented  under  control  of  mission  C&D  application 
software.  The  requirements  for  these  modes  are  defined  in  a  Pilot/Operational 
Sequence  Interface  Control  Document  (ICD). 

3.2.4  DAIS  Mission  Software 


The  DAIS  Mission  Software  (MSW)  is  the  set  cf  programs  which  support 
and  perform  the  avionics  functions  required  for  the  DAIS  Close  Air  Support  (CAS) 
mission.  To  control  and  perform  these  functions,  the  MSW  contains  both  Execu¬ 
tive  and  Application  Software. 

3.2.4. 1  Executive 


The  executive  is  the  operating  system  for  MSW.  It  is  organized  into 
the  local  executive  and  the  master  executive. 
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3.2.4. 1.1  Local  Executive 


Each  DAIS  processor  contains  a  local  executive.  The  local  execu¬ 
tive  software  is  table-driven.  It  performs  the  following  functions: 

1.  Process  Control  -  provides  services  for  the  application 
software  to  activate  and  deactivate  periodic  and  non¬ 
periodic  tasks  when  appropriate  conditions  have  been  met. 
These  conditions  are  based  upon  logical  settings  (on  or 
off)  of  real-time  events. 

2.  Event  Control  -  provides  the  mechanism  for  setting, 
resetting,  and  evaluating  real-time  events  which  commun¬ 
icate  conditions  (on  or  off)  signalled  between  tasks  in 
the  same  or  different  processors. 

3.  Data  Control  -  guarantees  integrity  of  shared  data  and 
provides  mechanism  for  transmission  and  reception  of 
data  over  the  multiplex  bus. 

4.  Processor  Initialization  -  provides  initialization  for 
processor  power  transient  recovery,  initializes  program 
loads,  and  performs  minor  cycle  synchi ruization  with  the 
Other  processors. 

3.2.4. 1.2  Master  Executive 


One  of  the  DAIS  processors  contains  the  master  executive.  The 
master  executive  is  table-driven.  It  manages  the  system  configuration  by 
performing  the  following  functions: 

1.  System  Synchronization  Control  -  allocates  time  segments 
(minor  cycle  and  major  cycle)  for  synchronous  messages 
and  performs  minor  cycle  synchronization  by  transmitting 
minor  cycle  master  function  mode  commands  to  the  other 
processors. 

2.  Bus  Control  -  controls  transmission  of  synchronous  and 
asynchronous  messages  over  the  multiplex  data  bus. 

3.  System  Error/ Failure  Management  -  monitors  and  analyzes 
errors  and  failures  on  both  bus  and  terminal  devices. 
Initiates  message  retry  procedures  to  recover  from 
message  errors. 

4.  Configuration  Management  -  detects  and  isolates  permanent 
device  failures,  maintains  system  configuration  status, 
reports  failure  to  the  application  software,  and  initiates 
backup  or  recovery  operation  if  required. 

5.  Mass  Memory  Management  -  provides  for  retrieving  and 
storing  information  from  the  mass  memory  on  request. 
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3. 2. 4. 2  Appl  icatioii  Software 

The  application  software  performs  the  tasks  associated  with  the 
avionics  requirements  of  the  mission.  The  application  software  is  divided 
into  eleven  functional  areas. 

•  Navigation 

•  Guidance 

•  Weapon  Delivery 

•  Position  Update 

•  Display 

•  Miscellaneous  Functions 

•  Stores  Management 

•  Pilot  Control 

•  System  Control 

•  Common  Subroutines 

•  System  Functions 

Table  3  lists  and  briefly  describes  all  the  programs  in  each  of 
the  functional  areas. 

3. 2. 4. 2.1  Navigation 

The  navigation  software  computes  aircraft  position  and  velocity 
and  related  information  used  by  the  pilot  and  by  avionics  algorithms.  The 
Navigation  programs  include  three  navigation  modes  (INS,  Dead  Reckoning, 
and  TACAN),  associated  programs,  and  programs  to  interface  with  the  appro¬ 
priate  avionic  sensors. 

3. 2. 4. 2. 2  Guidance 


The  guidance  software  computes  flight  path  deviations  and  handles 
pilot  requests.  It  calculates  and  displays  to  the  pilot  information  needed 
for  steering.  The  guidance  software  provides  the  six  steering  modes:  Command 
Track,  Command  Nav,  Command  Heading,  Command  Altitude,  ILS,  and  TACAN. 

3. 2. 4. 2. 3  Weapon  Delivery 

The  weapon  delivery  programs  perform  the  calculations  to  aid  the 
pilot  in  releasing  weapons.  Variables  such  as  ejection  angles,  range-to- 
target,  miss  distance,  stick  length,  and  bomb-fal 1 -1 ine  are  computed  and  dis¬ 
played.  Two  delivery  modes,  CCIP/Auto  and  CCIP/Manual ,  are  available. 

3. 2. 4. 2. 4  Position  Update 

The  position  update  programs  in  conjunction  with  the  weapon  delivery 
range  algorithms  allow  the  pilot  to  update  the  aircraft  position  based  on  known 
waypoint  or  target  positions.  Three  position  update  modes  are  available: 

INU  HUD  update.  Flyover  update,  and  FLIR/Laser  update. 

3. 2. 4. 2. 5  Display 

The  display  software  presents  information  to  the  pilot  in  the  cockpit. 
It  controls  data  sent  to  the  MPDG's  and  the  IMFK  and  MFK.  It  provides  specific 
display  messages  to  drive  the  symbols  and  graphics  on  the  DAIS  displays. 
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TABLE  3.  APPLICATION  GUI  IWAKE  PROGRAMS 


FUNCTIONAL  AREA 

APPLICATION  sor;wAi-.f 

DESCRIPTION 

Navigation 

SP01NAVCONFROL 

Navigation  controller 

SP02NAVPARMS 

Calculates  flight  parameters 
from  INS  data 

SP03NAVINS 

Interfaces  with  INS  and  computes 
wander  angle,  latitude,  iner¬ 
tial  velocity 

SP04TACANNAV 

Calculates  latitude,  longitude, 
velocities  using  TACAh 

SP05DRNAV 

Implements  Dead  Reckoning  navi¬ 
gation 

SP06ALIGN 

Controls  timing  of  INS  alignment 

SP07NAVQATA 

Computes  transformation  matrix 

SP08TACSEI. 

Selects  TACAN  station  to  be  used 
in  TALAN  Area  Naviqation 

QP01 INSOUTMODE 

Outputs  mode  and  power  to  INS 

QP02INSOUTDATA 

Outputs  Darometric  altitude  to 

INS 

QP03INSOUTUPDATE 

Outputs  direction  cosines  and 
longitude  to  INS 

QP04INSINDATA 

Inputs  INS  data 

GUIDANCE 

SPI0STEERCONTROL 

Guidance  controller 

SP11STEER 

Main  task  of  steering  function 

SP12DESTI NAT I ON 

Changes  command  nav  steering 
destination 

QP15TCN0UT 

Outputs  mode  and  channel  select 
to  TACAN 

QP16TCNIN 

Inputs  TACAN  range,  bearing , range 
rate,  status 

QP20ILSOUT 

Outputs  Power  and  frequency  to 

ILS 

QP21ILSIN 

Inputs  glideslope  and  localizer 
deviation 

WEAPON  DELIVERY 

SP40ATTVEL 

Calculates  air  mass  velocity  and 
ejection  angles 

SP41WDC0NT 

Weapon  Delivery  controller 

SP42AIMING 

Controls  aiming  reticle 

SP43FLR 

FLR  (Laser  Ranger)  pointing 
anql es 

SP44BALL 1ST I CS 

Ballistics  algorithm 

SP45WPNRANGE 

Sets  steering  modes  and  in-range 
flags 

SP46SC 

Solution  cue  position 

SP47BFL 

Bomb  fall  line  parameters 

SP48PD 

Positions  the  pull-up  cue 

SP50CCIP 

Solution  cue  for  CCIP  manual 

SP51WDINIT 

Initializes  weapon  delivery 
software 
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TABLE  3.  APPLICATION  SOFTWARE  PROGRAMS  (CON'T) 


FUNCTIONAL  AREA 

APPLICATION  SOFTWARE 

DESCRIPTION 

WEAPON  DELIVERY 

SP52RANGING 

Computes  target  range 

(CON'T) 

SP53RELEASE 

Time-to-release 

QP50LSRINRNG 

Inputs  range  and  status  from 

Laser  Ranger 

QP51LSROUTDATA 

Outputs  data  to  Laser  Ranger 

QP55SCUIN 

Converts  SCU  data  into  internal 
format 

POSITION  UPDATE 

SP90POSUPDATE 

Coordinates  pilot  slewing  the 
aiming  reticle  and  designat¬ 
ing  to  perform  a  position 
update 

SP91POSUPDATECONTROL 

Position  update  controller 

DISPLAY 

OP01MMPLIGHTS 

Changes  MMP  light  state 

DP02IMFKLIGHTS 

Lights  the  IMFK  Brute  Force  keys 

DP03MFKL IGHTS 

Lights  the  MFK  Brute  Force  keys 

DP04PAGE 

Displays  entire  IMFK/MFK  page 

DP21MPDG 

Synchronous  DISP  for  messages  to 
MPDG 

DP23MPDGDISPLAYASS IGN 

Formats  and  sends  data  to  MPDGs 

DP24MPDGWPTINIT 

Initializes  waypoints  for  MPDG 

DP25MPDGTABLDISP 

Sends  message  to  MPDG1 

DP30FLASHSYMBOLS 

Controls  flashing 

DP52ST0RESTAT 

Changes  MPDG  stores  option  format 

DP60BLINKFD 

Blinks  the  flight  director 

DP51MAPUPDATE 

Determines  which  map  data  blocks 
are  needed 

QP71SCUDEKOUT 

Output  lamps,  DEK  activity, 
display  power 

MISCELLANEOUS 

SP20ADCOMP 

Air  Data  computations 

FUNCTIONS 

SP21WIND 

Computes  wind  velocity 

QP25RDRALTOUT 

Outputs  power  and  test  bits  to 
Radar  Altimeter 

QP26RDRALTIN 

Inputs  Altitude  and  Status  from 
Radar  Altimeter 

QP40ADIN 

Inputs  Air  Data 

QP43UHF0UT 

Outputs  frequency  and  mode  to 

UHF 

QP49GEARIN 

Inputs  aircraft  status 

STORES 

SP70STORESCON 

Stores  management  controller 

MANAGEMENT 

SP71STORESCON1 

Deactivates  weapons 

SP72MK82CON 

Controls  MK-82 

SP76PJETT 

Performs  programmed  jettison 

SP77EJETT 

Performs  emergency  jettison 

SP78STORESINIT 

Brings  loaded  stores  to  quies¬ 
cent  state 

QP60ARMIN 

Inputs  armament  switches 

QP80MK82 

MK-82  control 

QP81STA1REL 

Station  1  Release 

TABLE  3.  APPLICATION  SOFTWARE  PROGRAMS  (DON'T) 


FUNCTIONAL  AREA 

APPLICATION  SOFTWARE 

DESCRIPTION 

PILOT  CONTROL 

CP03MMPREQPROC 

Handles  MMP  Pilot  requests 

CP04IMFKREQPROC 

Interprets  IMFK  key  inputs 

CP05MFKREQPROC 

Interprets  MFK  key  inputs 

CP07HANOLER 

Carries  out  actions  when  IMFK 
side  key  is  pressed 

QP70DEK1  IN 

Inputs  data  from  DEK1  and  DEK2 

SYSTEM  CONTROL 

CP01MASTSEQ 

Initializes  application  software 

CP02CONF IG 

Sets  up  application  software 
configuration 

CP11WOGSIMKEY 

Weight-off-gear  simulated  key 
producer 

CP12FLYTOSIMKEY 

Fly-to-point  simulated  key 
producer 

CP13WHLSIMKEY 

Wheels  down  simulated  key 
producer 

CP14FLAPSIMKEY 

Flaps  set  simulated  key  producer 

CP15MMPILLS5MKEY 

MMP  illegal  simulated  key  pro¬ 
ducer 

CP16MMPNIMPLSIMKLY 

Non- implemented  simulated  key 

CP17WONGSIMKEY 

Weight-on-gear  simulated  key 
producer 

CP180FFFPSIMKEY 

Off- f 1 ight-plan  simuljted  key 
producer 

CP19T02DIMWPTSIMKEY 

To  2  dimensional  waypoint  simu¬ 
lated  key  producer 

CP20OUTBNDSIMKEY 

Outbound  intercept  simulated  key 
producer 

CP30WTOFFGEAR 

Take-off/Cl imb  simulated  key 
producer 

CP40MMCQPY 

Copies  Master  Mode 

CP50DISPCONTROL 

Activates  CP07 

COMMON 

ALTSET 

Formats  reference  pressure  for 

SUBROUTINES 

IMFK 

BINARY 

Performs  binary  searcn 

CNTRST 

Formats  weapon  station  informa¬ 
tion 

CONVER 

Converts  radians  to  degrees  and 
seconds 

DEGREE 

Converts  radians  to  degrees 

DENORM 

Converts  floating  point  to 
fixed  point 

ELEVDH 

Formats  IMFK  legend 

FLOATF 

Converts  floating  point  to  ASCII 

FLYTOF 

Formats  the  fly-to  display 

FUZING 

Formats  the  fuzing  for  display 

ILSCHN 

Formats  the  ILS  CHNG  IMFK  legend 

INTERV 

formats  the  interval  for  the  IMFK 
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TABLE  3.  APPLICATION  SOFTWARE  PROGRAMS  (CON'T) 


FUNCTIONAL  AREA 

APPLICATION  SOFTWARE 

DESCRIPTION 

COMMON  SUB- 

JETPAG 

Formats  the  jettison  programs 

ROUTINES  (CON 1 V) 

LATLON 

Converts  radians  to  character 
display 

LIMIT 

Limits  an  integer  to  a  specified 
range 

LIMITF 

Limits  a  floating-point  to  a 
specified  range 

MAGVAR 

Formats  the  magnetic  variation 

MODEFO 

Formats  the  weapon  delivery  mode 

MTXV 

Multiplies  matrix  transpose 
times  a  vector 

MXV 

Multiplies  matrix  times  vector 

MXM 

Multiplies  matrix  by  matrix 

NORMAL 

Normalizes  a  fixed-point  number 

OFFSET 

Formats  the  offset  for  display 

QUANID 

Formals  the  quantity/weapon  ID 

REVERS 

Reverse  the  bit  pattern 

SMOOTH 

Performs  first-order  lag 
smoothing 

STATIO 

Formats  the  stations 

TCNCHN 

Formats  the  TCNCHNG  legend 

TRANSP 

Performs  matrix  transpose 

S15ENC 

Converts  integer  to  ASCII 

UHFCHN 

Formats  the  UHFCHNG  data 

VADD 

Adds  two  vectors 

VDOT 

Performs  dot  product 

VUPDATE 

Performs  vector  operation 

VXV 

Multiplies  two  vectors 

WINDSE 

Formats  the  windset  display 

SYSTEM  FUNCTIONS 

SIN 

Sine 

COS 

Cosine 

SIND 

Sine  (de>  s) 

COSD 

Cosine  (du  . ees ) 

ASIN 

Arc  sine 

ACOS 

Arc  cosine 

ATAN 

Arc  tangent 

SINH 

Hyperbolic  sine 

COSH 

Hyperbolic  cosine 

TANH 

Hyperbolic  tangent 

MAX 

Maximum 

TAN 

Tangent 

LN 

Natural  logarithm 

LOG 

Logarithm 

SQRT 

Square  root 

EXP 

Exponential 

ATAN2 

Two-argument  arc  tangent 
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3 . 2 . 4 . 2 . 6  Miscellaneous  Functions 

The  miscellaneous  functions  include  wind  ano  air  d aia  calculations. 
They  also  provide  interfaces  with,  the  air  data  sensors,  tnc  radar  altimeter, 
the  UHF  radio,  and  the  gear. 

3 . 2 . 4 . 2 . 7  Stores  Management 

The  stores  management  software  maintains  invento  -o  of  the  weapons 
on  board  the  aircraft.  It  keeps  track  of  the  number  and  type  of  weapons  as 
well  as  their  state. 

3. 2. 4. 2. 8  Pilot  Control 


The  pilot  control  software  responds  to  the  pilot's  requests  and  invokes 
the  appropriate  application  functions  that  generate  information  for  displays 
or  for  controlling  avionic  support  subsystems. 

3. 2. 4. 2. 9  System  Control 

The  system  control  software  schedules  and  controls  the  application 

software. 

3.2.4.2.10  Common  Subroutines 


The  common  subroutines  (COMSUB's)  are  a  set  of  reentrant  programs. 
They  perform  mathematical  operations  such  as  matrix  multiplication  as  well  as 
data  manipulations  such  as  reformatting. 

3.2.4,2.11  System  Functions 

The  system  functions  include  the  mathematical  and  trigonometric 
functions  such  as  sine  and  square  root. 

3. 2. 4. 3  Mission  Software  Architecture 


The  mission  software  is  modular  and  flexible.  It  can  accommodate 
mission-to-mission  changes  as  well  as  changes  in  the  complement  of  avionic 
sensors.  It  allows  for  modification  of  both  the  executive  and  the  application 
software  which  greatly  facilitates  implementing  the  DAIS  architecture  on  other 
ai rcraft. 


The  application  software  is  organized  in  a  hierarchical  control 
tree  structure.  Each  program  is  either  a  controller  or  a  calculator.  A 
controller  schedules  a  particular  set  of  calculators.  Each  controller  is, 
in  turn,  scheduled  by  a  controller  at  a  higher  level. 

The  master  sequencer  is  at  the  top  of  the  application  software 
hierarchy.  It  controls  the  request  processors,  configurator ,  and  subsystem 
status  monitor.  This  master  sequencer  is  only  required  in  the  master 
processor. 
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The  configurator  schedules  the  remaining  tasks.  It  defines  the  set 
of  application  functions  to  be  invoked  by  request  from  the  request  processors 
or  the  subsystem  status  monitor.  It  also  generates  a  new  set  of  available 
functions  upon  significant  chanqes  in  mission  phasing  or  equipment  moding. 

This  set  of  functions  is  based  on  a  global  knowledge  of  overall  system  status. 

The  structures  described  above  arp  further  divided  into  modular 
components.  Each  component  is  a  closed  program,  that  is  a  program  with  only 
one  entry  and  one  exit  point.  In  addition,  each  program  is  under  control  of 
a  program  at  the  next  higher  level  of  the  hierarchy.  Also,  the  components 
isolate  separate  hardware  functions;  this  localizes  the  impact  of  equipment 
changes  and  allows  for  mission-to-mission  system  changes. 

Structured  programming  techniques  are  used  to  increase  reliability 
and  understanding  and  to  eliminate  intricate  logic  that  is  difficult  to 
validate  and  verify.  Only  closed  logic  structures--logic  structures  which 
have  a  single  entry  point  and  a  single  exit  point--are  employed  in  the  con¬ 
struction  of  program  components.  To  further  emphasize  standardization  and 
understanding,  the  higher  order  language  JOVIAL  J73  is  used  for  development 
of  the  Mission  Software.  JOVIAL  is  not  used  for  those  portions  of  the  program 
where  computer  time  must  be  minimized  or  a  high  degree  of  numerical  accuracy 
is  required  or  interface  with  processor  or  bus  controller  hardware  is  performed. 

3 . 3  Other  Elements 

3.3.1  System  Mass  Memory 

This  optional  subsystem  supports  the  DAIS  capabilities  to  load/ 
reload  program  modules.  In  the  ITB,  it  is  actually  a  simulation  of  a  bubble 
memory  device.  The  simulation  is  implemented  in  the  universal  remote  terminal 
(URT). 


A  fixed  RT  address  is  required  for  the  system  mass  memory  in  order 
for  it  to  be  accessed  by  the  bootstrap  routine  during  startup.  The  system 
mass  memory  has  four  basic  operations,  as  follows: 

Address  Select  -  to  set  a  starting  address  for  the 
mass  memory  and  specify  if  synchronous  or  asynchronous 
operations  are  to  be  performed.  Also  to  set  read  mode 
or  set  write  mode. 

Address  Retrieve  -  to  obtain  the  current  (i.e.  next  to 
be  accessed)  mass  memory  address  and  settings  of  the 
Read/Write  and  Sync/Async  flags. 

Read  -  to  transfer  data  from  the  mass  memory  and  advance 
the  current  address  by  the  number  of  words  transferred. 

Write  -  to  tr>  nsfer  data  to  the  mass  memory  and  advance 
the  current  address  by  the  number  of  words  transferred. 
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The  format  of  the  messages  associated  with  eacn  of  the  basic 
functions  is  shown  in  Figure  11.  In  this  example,  Receive  (T/R=0)  sub¬ 
address  17  is  used  for  Address  Select;  Transmit  subaddress  17  is  used  for 
Address  Retrieve;  Transmit  subaddress  18  is  used  for  Read;  arid  Receive 
subaddress  18  is  used  for  Write.  Ihese  are,  of  course,  arbitrary  choices 
that  may  be  changed  by  the  system  designer.  The  significant  point  is  that 
the  startup  program  must  know  the  bus  address  of  the  mass  memory  and  the 
subaddress  of  each  function. 

These  messages  have  some  bit  definitions  unique  to  the  system 
mass  memory.  The  sync/async  bit  in  the  address  select  command  tells  tne 
unit  whether  or  not  the  Last  Coninand  Word  is  to  be  included  as  the  first 
data  word  of  a  Read  operation. 

The  read/write  bit,  also  in  the  Address  Select  message,  specifies 
whether  subsequent  operations  will  be  writing  data  to  or  reading  data  from 
the  system  mass  memory.  This  information  is  required  to  properly  manage 
data  buffers  internal  to  the  interface.  It  also  provides  a  first  level  of 
security,  reducing  the  chances  of  inadvertent  data  destruction. 

To  meet  the  multiplex  bus  response  times,  a  buffer  interface  is 
necessary.  Further,  the  buffer  size  is  selected  so  that  the  time  to  load 
the  buffer  from  the  memory  device  is  less  than  the  time  to  transmit  the 
buffer  contents  over  the  multiplex  bus.  A  standard  double  buffering  tech¬ 
nique  can  then  support  a  continuous  data  flow  and  no  delays  need  be  encountered 
after  the  initial  access. 

The  bits  defined  in  the  status  word  provide  the  Master  Executive 
or  Startup  Loader  with  information  on  why  the  most  recent  operation  was  not 
successful.  These  are  interpreted  as  follows: 

ME  -  Message  Error  -  indicates  data  was  not  received 
correctly  off  the  bus.  The  data  has  not  been 
accepted,  and  the  address  has  not  been  advanced. 

BSY  -  Busy  -  indicates  the  data  transfer  could  not  take 
place;  e.g.,  buffer  full,  access  in  progress. 

TF  -  Terminal  Fail  -  indicates  an  unrecoverable  device 
error  occurred  on  the  most  recent  operation. 

The  system  mass  memory  is  not  to  be  confused  with  the  C&D  mass 
memory  unit  (MMU).  The  MMU  is  a  component  of  the  C&D  subsystem  though  a 
system  designer  may  opt  to  implement  these  logically  distinct  units  on  a 
single  physical  device.  (In  this  case,  the  interface  unit  would  be  required 
to  resolve  any  access  conflicts  internally  in  a  manner  transparent  to  the  bus 
operations. ) 

Alternatively,  a  specific  implementation  may  choose  to  economize  by 
omitting  the  system  mass  memory,  thereby  foregoing  the  inflight  reload  capa- 
bil ity. 
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FIGURE  11.  SYSTEM  MASS  MEMORY  MESSAGE  FORMATS  (Page  1  of  2) 


3.3.2 


Processor  Control  Panel _ (PCP ) 

'  \ 

The  Processor  Control  Panel  provides  switches  to  separately  enable 
power  to  each  side  (A  and  B)  of  the  multiplex  system  and  to  each  of  the  pro¬ 
cessors.  Two  toggle  switches  and  two  push  buttons  provide  the  pilot  control 
over  system  load  and  system  restart  operations. 

The  advisory  caution  panel  (ACP)  provides  a  display  of  hardware  and 
software  status  during  the  startup  process.  This  is  shown  in  Figure  12.  The 
two  panels  are  normally  referenced  together  as  the  PCP/ACP.  The  lamp  test 
button  on  the  PCP  provides  a  local  test  of  all  lights  and  backlighted  push 
buttons  on  both  panels. 

3 . 4  Non-Real -Time  Support  Software 

The  DAIS  non-real -time  support  software  provides  the  tools  to 
develop,  generate,  test,  and  partition  the  mission  software  for  the  specific 
avionics  configuration.  The  non-rea 1 -time  support  software  includes  the 
JOVIAL  Compiler  and  the  Partitioning  Analyzing  and  Linkage  Editing  Facility 
(PALEFAC) . 

3.4.1  JOVIAL  Compiler 

The  JOVIAL  Compiler  is  a  program  which  translates  high-order- 
language  source  code  into  object  code.  Two  versions  of  the  JOVIAL  language 
and,  therefore,  two  versions  of  the  JOVIAl  compiler  were  used  in  developing 
the  OAIS  mission  software.  Mission  Software  was  first  written  in  JOVIAL 
J73/I.  In  1980,  all  Mission  Software  was  converted  to  JOVIAL  J73.  Both 
versions  of  the  compiler  serve  the  same  function  and  fill  the  same  role  in 
the  OAIS  system  architecture. 

The  JOVIAL  compiler  generates  object  modules  which  can  be  loaded 
and  executed  on  specified  target  computers  (such  as  the  DAIS  processors  or 
the  DECsystem-10  computer).  The  JOVIAL  language  is  machine-independent. 

It  uses  self-explanatory  English  words  and  familiar  notation  for  algebraic 
and  numerical  computations  and  logical  operations.  The  JOVIAL  compiler  pro¬ 
vides  a  common,  powerful,  and  easily  understandable  programming  language  for 
a  wide  range  of  applications.  The  compiler  provides  a  capability  for  sharing 
data  among  interdependent  programs  or  tasks  through  a  conmunication  pool 
(compool ) . 


The  JOVIAL  compiler  is  designed  to  be  easily  retargeted  to  produce 
object  code  for  a  new  and  unspecified  computer.  It  is  also  designed  to  be 
easily  rehostable  to  another  host  computer.  Initially,  the  compiler  was  hosted 
on  the  DECsystem-10  computer  system  and  targeted  for  the  DAIS  processor  and 
DECsystem-10. 

The  structure  of  the  compiler  is  shown  in  Figure  13.  The  system 
programmer  generates  the  source  input  and  compool  input  files.  The  programmer 
then  compiles  the  source  program  using  the  compiler  which  produces  source 
listings,  cross  references,  object  listings,  and  the  relocatable  object  files 
for  the  selected  target  computer. 
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The  output  of  the  compilation  is  a  relocatable  object  file.  !r. 
order  to  execute  the  program  on  the  DECsystem- iO,  the  object  file  must  be 
converted  to  core  image  form  using  the  DECsystem- 10  (LINK-10)  1  inker/ loader . 

In  order  to  execute  the  program  on  the  DAIS  processor,  it  must  be  converted 
to  core  image  form  using  the  HBC  linker/loader. 

The  JOVIAL  Programmer  User's  Manual  provides  definition  of  the  J73 
language,  properties,  and  statements  including  examples  of  how  to  write  a  J73 
program.  The  guide  also  presents  a  syntactic  description  of  the  language 
elements  with  examples  and  necessary  information  for  the  user  to  write,  con- 
pile,  load  and  execute  programs  on  the  target  computers. 

3.4.2  Part itioning  Analysing  and  Linkage  Editing  Facility  (PALEFAC) 

PALEFAC  is  a  non-real -time  support  software  tool  for  use  by  the 
system  designer  and  application  programmer  to: 

1.  Build  the  data  tables  for  the  DAIS  local  and 
master  executives. 

2.  Provide  bus  analysis  and  module  partitioning 
information. 

3.  Produce  the  executive  tables  in  J73  source  code. 

4.  Generate  linket  command  files  for  each  DAIS  pro¬ 
cessor  for  the  DECsystem- 10  Linker  or  DAIS 
Processor  Linker. 

PALEFAC  is  used  as  a  stand-alone  tool.  PALEFAC  consists  of  three 
basic  programs,  as  shown  in  Figure  14:  PALEFAC  pre-processor ,  PALEFAC  main 
program,  and  PALEFAC  module  input  ( PM I )  decoder. 

PALEFAC  is  used  to  build  the  mission  software  load  modules  for  each 
of  the  DAIS  processors.  Inputs  to  PALEFAC  are  the  Application  Software  mod¬ 
ules  including  the  executive  service  requests  generated  by  the  application 
programmer  in  J73  source  code.  The  pre-processor  reads  each  application  module 
and  creates  a  record  for  each  application  module  in  the  PMI  file. 

The  system  designer  prepares  a  PALEFAC  Global  Input  (PGI)  file  based 
upon  the  specific  system  configuration,  partitioning  of  application  tasks  to 
eacn  processor,  and  bus  messanes  to  each  terminal.  This  would  include: 

a.  Bus  Messages 

•  To/from  data  block  name  or  Terminal  Address/ 

Subaddress 

•  Cycle  (period  and  phase)  for  synchronous 
transmissions 

•  Activity  request  identification  for  asynchronous 
transmi ssion 
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FIGURE  14.  PALEFAC  OVERVIEW 


•  Word  count 


•  Class  for  message  error  retry 

b.  List  of  all  tasks  or  modules  for  each  processor 

c.  Override  directives 

d.  Number  of  processors  in  the  system  configuration  and 
address  of  each  terminal 

The  system  designer  also  generates  the  PALEFAC  Auxiliary  File  (PAL)  for  common 
subroutines  (comsubs)  and  common  communication  data  blocks  (compools). 

The  PALEFAC  main  program  builds  the  executive  tables  and  linker 
command  files  based  upon  the  system  designer  specified  configuration.  The 
output  of  PALEFAC  is  the  PALEFAC  mission  files  (PMD),  PALEFAC  Partitioning 
Information  Files  (PPI),  and  test  output  files  shown  in  Figure  11.  The  PHD 
files  contain  all  the  executive  tables  including  the  bus  control  tables  in 
J73  source  code.  The  PPI  files  contain  the  linker  commands  for  each  pro¬ 
cessor  and  specify  all  the  mission  software  modules  (e.g.  executive  modules, 
application  tasks,  comsubs,  and  executive  tables)  in  order  for  the  linker  to 
produce  the  load  modules  for  each  processor.  PALEFAC  also  produces  text 
output  files  listing  all  the  PALEFAC  input  files,  the  output  files,  and  error 
messages . 

3.4.3  Assemblers/Linker 


ALAP  is  a  retargetable  assembler  written  in  Fortran  IV  and  hosted 
on  the  DECsystem-10  computer  at  the  AF  Wright  Aeronautical  Laboratory.  The 
assembler  can  be  retargeted  to  a  variety  of  machine  languages.  Its  function 
is  to  translate  assembly  language  source  into  object  'nodules  which  can  be 
loaded  and  executed  on  a  specified  target  computer  (e.g.  AN/ AY K- i 5  processors, 
AN/AYK-15A  processors,  DECsystem-10  computer)  or  into  relocatable  files  for 
further  processing  by  LINKS. 

LINKS  is  a  target-independent  linker  written  in  Fortran  IV  and 
hosted  on  the  DECsystem-10  computer  at  the  AF  Wright  Aeronautical  Laboratory. 
Its  function  is  to  combine  relocatable  files  produced  by  the  ALAP  assembler 
and/or  the  JOVIAL  compiler  into  a  single  object  file  ready  for  execution  on 
a  specified  target  computer. 
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4.0 


DAIS  SYSTEM  CHARACTERISTICS  AND  FEATURES 


The  performance  characteristics  of  DAIS  include  system  functional 
control  characteristics  as  well  as  system  architecture  features  and  attributes 
included  in  the  design  of  DAIS  core  elements.  These  sections  address  the  system 
control  features  and  the  primary  characteristics  which  are  unique  and  important 
to  the  DAIS  concept. 

4. 1  System  Control  Procedures 

The  DAIS  architecture  and  integrated  system  design  result  in  a 
special  set  of  functional  requirements,  designated  system  control  procedures, 
which  include  system  startup/restart,  control  of  the  bus  communication,  and 
utilization  of  redundancy  in  the  event  of  core  element  failures.  The  system 
and  bus  control  functions  are  distinguished  from  mission  avionic  functions 
which  support  the  specific  mission  tasks.  The  mission  avionic  functions  are 
composed  of  navigation,  guidance,  weapon  delivery,  communications,  target 
acquisition  and  track,  stores  management,  and  subsystem  management. 


Another  important  group  of  functions,  on-board  tests,  utilize  both 
hardware  and  software  to  isolate  in-flight  failures.  This  allows  utilization 
of  redundancy,  maintains  a  complete  updated  status  of  every  equipment  on  the 
system,  and  provides  isolation  of  failure  to  LRU  levels  with  a  minimum  of 
auxiliary  group  equipment. 

4.1.1  System  Startup/Restart  Operations 

The  overall  objective  of  the  system  startup/restart  procedures  is  to 
give  the  pilot  control  of  the  system  configuration  and  to  provide  a  verification 
of  the  hardware  and  software  prior  to  entering  normal  system  operations. 

The  pilot  controls  the  system  via  the  Processor  Control  Panel  (PCP). 
The  power  enable  switches  allow  him  to  remove  a  processor  from  the  system  by 
powering  it  down.  The  GROUND  position  of  the  startup  switch  permits  him  to 
specify  an  initial  startup  as  opposed  to  a  restart,  indicated  by  the  INFLIGHT 
position.  The  START  button  permits  him  to  request  the  use  of  software  already 
loaded,  while  the  LOAD  button  allows  him  to  force  the  reload  of  all  software. 

Of  course,  the  LOAD  function  is  supported  only  when  a  system  mass  memory  is 
configured  in  the  system. 

In  addition  to  the  pilot-initiated  restarts,  the  system  will,  under 
certain  limited  circumstances,  perform  an  automatic  restart.  It  is  essential 
that  an  automatic  restart  have  minimal  impact  on  continued  system  operation. 

This  consideration  defines  the  need  for  a  "warm  start"  initialization  of  soft¬ 
ware  as  opposed  to  the  “cold  start"  associated  with  normal  system  startup. 

"Cold  start"  assumes  a  fully  operational  configuration.  It  involves 
the  complete  initialization  of  executive  and  application  software  and  the 
assignment  of  initial  values  to  events  and  data. 

"Warm  start"  continues  the  current  operational  status.  A  partial 
initialization  of  the  executive  is  performed,  current  data  is  maintained,  and 
application  tasks  and  events  are  assigned  to  a  known,  predetermined  state. 
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The  various  startup/^estart  cases  are  summarized  in  Table  4. 

As  is  evident  from  this  table,  it  is  important  the  pilot  set  the  startup 
switch  before  powerinq  up  the  processors.  Otherwise,  the  power-up  would 
look  like  a  transient  recovery.  Conversely,  the  pilot  must  return  the  switch 
to  the  INFLIGHT  position  at  the  completion  of  a  normal  startup.  Failure  to 
do  so  would  allow  a  transient  to  brine  the  system  to  a  stop. 

4 . 1 . 1 . 1  Normal  Sy st em  S tartup 

Each  processor  is  equipped  with  a  read  only  memory  (ROM)*,  which  is 
enabled  when  the  power  up  condition  is  detected.  The  ROM  contains  sufficient 
instructions  for  the  processors  to  perform  self  tests,  determine  the  integrity 
of  loaded  software  and  arbitrate  control  of  the  multiplex  bus.  The  ROM  may 
contain  additional  functions  as  desired  for  any  specific  implementation,  but 
normally  considerations  of  stability  and  size  would  indicate  only  essentials 
should  be  in  the  ROM.  The  minimum  ROM  contents  are  dictated  by  the  requi remen t 
that  the  ROM  be  capable  of  starting  or  restarting  a  system  without  a  systen> 
mass  memory. 

As  each  processor  senses  power-up,  it  enables  the  ROM  and  begins 
execut’ng  at  location  zero.  Memory  protection  is  established,  interrupts 
are  cleared,  and  self  tests  are  performed  on  the  orocessor/BCM. 

At  the  completion  of  self  tests,  software  is  verified  and  one  process'" 
is  established  as  controller  of  the  multiplex  bus.  The  other  processors  rerai> 
in  remote  mode,  prepared  to  transmit  the  results  of  self  tests  and  software 
verification.  The  controller  polls  all  possible  processors  for  this  informal!'"  • 
to  determine  the  conf iguration  to  be  run.  A  processor  is  included  in  the 
configuration  if  it  passed  self  test  and  it  successfully  communicates  on  the 
multiplex  bus. 

Software  verification/loading  is  the  final  phase  of  the  startup  pro¬ 
cess.  Based  on  the  configuration  which  is  operational  ,  the  system  loader 
accesses  a  startup  configuration  table  to  determine  the  load  module  required 
in  each  processor.  If  the  required  software  is  not  present,  it  is  loaded  from 
system  mass  memory,  and  the  verification  process  repeated.  When  it  is  confirmee 
that  all  processors  are  properly  loaded,  the  controller  directs  each  processor 
to  perform  initial ization.  The  controller  then  enters  its  own  initialization 
and  normal  system  operation  is  begun. 

4 . 1 . 1 . 2  System  Warm  Start 

System  Warm  Start  is  designed  primarily  as  a  response  to  a  system- 
wide  power  transient.  The  objective  of  a  warm  stai t  is  to  resume  operations 
as  quickly  as  possible.  The  procedure  starts  what  ;t  finds  and  verifies 
in  the  processors'  memory  and  does  not  perform  reloading.  The  pilot  will  be 
alerted  if  a  runnable  set  of  software  is  not  found. 


The  ROM,  in  effect,  overlays  the  first  four  thousand  words  of  memory  while 
invoked.  This  is  a  feature  of  the  AN/AYK-15A  processor  and,  since  it  is 
the  preferred  implementation,  the  startup  procedures  are  described  in  this 
context.  With  the  AN/AYK-15,  or  other  processor  not  equipped  with  a  ROM, 
the  startup  software  must  be  permanently  preserved  in  low  memory  and  memory 
protected  except  as  required  when  modifying  interrupt  vectors. 
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As  power  is  restored  to  each  processor,  it  will  enter  the  ROM, 
perform  self  tests,  verify  software  and  build  startup  status  information  as 
in  normal  startup.  The  absence  of  any  bus  activity  permits  one  of  the 
processors  to  assume  control  to  manage  the  warm  start.  The  fact  that  it  is 
a  warm  start  is  determined  by  the  INFLIGHT  position  of  the  start  switch  and 
the  absence  of  the  discretes  for  both  the  start  button  and  the  load  button. 

The  startup  configuration  table  defines  the  acceptable  nonfigurations 
for  a  warm  start  in  their  order  of  preference.  This  information,  along  with  the 
module  ID's  required  for  an  initial  load,  is  kept  in  the  fixed  information  table 
in  each  processor  to  facilitate  quick  transient  recovery.  If  the  procedure 
cannot  find  the  configuration  matching  the  initial  load  (which  by  definition  is 
the  most  preferred  configuration  for  a  warm  start)  it  then  goes  through  the 
restartable  list  trying  to  find  a  configuration  in  which  each  of  the  load  module 
ID's  can  be  found  in  some  processor. 

Should  no  restartable  load  set  be  found,  the  pilot  is  alerted  by 
the  master  caution  lamp.  The  startup  process  is  then  recycled  to  the  point 
of  reading  the  PCP  prior  to  identifying  the  configuration.  The  procedure 
will,  therefore,  automatically  detect  a  processor  that  recovers  from  a  power 
transient  much  slower  than  the  others.  It  will  also  respond  to  new  direction 
from  the  pilot  via  the  PCP. 

4.1.2  Normal  System  Operation 

In  normal  system  operation  one  of  the  processors,  designated  the 
master  processor,  contains  the  master  executive  and  controls  the  bus.  Each 
of  the  remaining  processors  is  designated  a  remote  processor  and  each  contains 
a  local  executive.  Application  software  is  distributed  among  all  the  processors. 

4 . 1 . 2 . 1  Bus  Control  Operation 

Bus  control  operation  is  concerned  with  the  control  of  the  bus  message, 
and  sequences  as  defined  in  MIL-STD-1553B  and  as  shown  in  Figute  6.  The  contro1 
of  bus  traffic  operations  provides  for  major/minor  cycle  synchronization ,  which 
is  maintained  via  transmission  of  minor  frame  (synchronize  mode  command)  messages 
to  each  remote  processor,  and  provides  for  both  synchronous  and  asynchronous 
bus  communication. 

The  synchronous  bus  traffic  is  controlled  by  a  predefined  bus  command 
list.  Asynchronous  messages,  which  are  predefined,  are  scheduled  by  the  master 
executive  based  upon  requests  from  terminals  or  application  tasks.  In  addition, 
the  bus  control  operations  themselves  may  generate  asynchronous  messages  in 
managing  exception  conditions. 

In  general,  asynchronous  operations  are  given  priority  over  synch¬ 
ronous  operations.  A  more  complete  breakdown  of  the  priorities  (1  is  the 
highest  priority,  6  is  the  lowest)  is  included  in  the  summary  of  bus  message 
operations,  Table  5. 

Message  protocol  is  defined  as  that  sequence  of  bus  messages  re¬ 
quired  to  perform  the  normal  multiplex  synchronous  and  asynchronous  operations 
and  to  support  the  error  detection  and  recovery  process.  In  order  to  insure 
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minimum  processor  executive  and  multiplex  bus  overhead  required  to  implement 
the  message  protocol,  two  concepts  are  introduced:  mode  commands  and  system 
control  procedures  (Figure  15). 

System  control  procedures  define  the  message  protocol  for  the  multi¬ 
plexed  data  bus  system.  They  serve  to  provide  the  executive  software  designer 
with  the  logical  decisions  required  to  manage  normal  system  operation.  They 
also  define  the  required  system  flow  to  detect  and  recover  from  random  bus 
message  errors  and  selective  terminal  failure  modes.  The  system  control  pro¬ 
cedures  serve  to  link  the  executive  mission  software,  bus  message  protocol , 
and  the  terininal-to-subsystem  interface  management. 

A  time  slice  approach  where  messages  occur  on  a  minor  cycle/major 
cycle  basis  is  used  to  control  bus  message  operations.  Messages  that  are 
transmitted  at  specific  iteration  rates  within  a  major  cycle  are  defined  as 
synchronous  messages.  Each  synchronous  message  is  assigned  a  period  and  phase 
for  transmission.  The  number  of  minor  cycles  per  major  cycle  is  specified  by 
the  system  designer.  An  example  is  128  minor  cycles  every  second  or  major 
cycle.  Messages  that  are  to  be  transmitted  on  a  demand  or  request  basis  and 
not  at  a  specific  phase  and  period  are  designated  as  asynchronous  messages. 
Table  5  summarizes  the  bus  message  operations. 

Bus  control  operations  provide  for  major/minor  cycle  synchronization 
and  for  synchronous  and  asynchronous  bus  message  transmissions  as  shown  in 
Figure  16.  The  synchronous  bus  messages  are  controlled  by  a  predefined  bus 
instruction  list.  The  bus  instruction  list  is  part  of  the  Master  Executive 
preloaded  tables.  It  contains  an  instruction  pair  for  each  synchronous  message 
that  is  transmitted  on  the  data  bus.  Since  not  every  message  is  transmitted 
every  minor  cycle,  the  instruction  lists  are  organized  so  that  the  instructions 
for  all  messages  with  the  same  period  and  phase  are  grouped  into  a  block.  Each 
block  ends  with  a  link  to  the  block  for  the  next  higher  message  rate  with  the 
appropriate  phase.  In  this  way  a  static  list  can  be  employed.  No  dynamic 
linking  is  required  each  minor  cycle;  the  Executive  just  starts  the  bus  at  the 
correct  place  ir,  the  list. 

Each  data  word  on  the  bus  is  transferred  to/from  the  processor's 
memory  in  real  time  via  a  direct  memory  access  channel.  The  address  at  which 
each  message  block  begins  is  constructed  by  combining  the  current  base  address, 
the  transmi t/recei ve  bit,  and  the  subaddress  into  the  pointer  address,  and 
then  fetching  the  contents  of  the  address  via  DMA.  Consecutive  data  words  are 
stored  in  contiguous  memory  locations  until  the  word  count  for  that  particular 
message  is  exhausted.  For  all  receive  operations,  each  message  block  is  pre¬ 
ceded  by  a  generated  tag  word  which  contains  the  current  minor  cycle  number, 
word  count  of  the  received  message,  and  a  message  error  flag. 

Asynchronous  messages  are  scheduled  by  the  master  executive  based 
upon  requests  from  remote  terminals,  application  tasks,  or  the  master  executive 
to  perform  message  error  or  terminal  failure  operations.  Subaddress  30  is 
dedicated  to  asynchronous  receive  messages.  After  receiving  an  asynchronous 
message,  the  BCM  interrupts  the  processor  and  the  local  executive  updates  the 
pointer  word  for  storing  data  before  restarting  the  BCM.  A  transmit  asynch¬ 
ronous  message  is  sent  via  subaddress  29  and  does  not  cause  an  interrupt. 
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The  first  word  of  all  asynchronous  messages  is  used  to  designate  the  sour-.e 
of  the  message.  This  asynchronous  message  identifier  is  used  by  the  local 
executive  to  process  the  data  or  identity  the  executive  services  action 
required. 

There  are  several  types  of  asynchronous  bus  message  operations 
based  upon  the  resource  making  the  request  and  protocol  to  process  the 
request  as  defined  in  Table  5.  Upon  receiving  the  request,  the  master  execu¬ 
tive  causes  the  BCM  to  halt  at  the  end  of  the  current  message  operation.  It 
then  executes  a  predefined  or  generated  bus  instruction  pair  to  initiate  the 
asynchronous  message  operation.  Figure  17  shows  the  message  protocol  sequence 
for  a  subsystem  connected  to  an  RT  requesting  service.  Asynchronous  operations 
are  used  for  pilot  panel  inputs  and  weapon  release  messages,  as  examples. 

Figures  18  and  19  show  asynchronous  message  protocol  sequences  for  interprocessor 
operations.  Interprocessor  messages  are  used  to  signal  master  mode  changes 
between  application  tasks  in  different  processors  and  steering/guidance  waypoint 
passage,  as  examples. 

4 . 1 . 2 . 2  Mode  Command  Operations 

The  mode  command  operations  are  indicated  by  using  a  subaddress  of  0 
or  31  with  the  specific  mode  code  in  the  word  count  field.  Table  6  specifies 
the  mode  commands  required  to  support  normal  operation  and  error/fa i 1 ure  manage¬ 
ment.  The  MIL-STD- 1553B  Mode  Codes  have  the  following  uses  in  DAIS. 

a.  Mode  codes  2,  18,  and  19  are  used  to  support  detection 
and  recovery  from  bus  message  errors. 

b.  Mode  codes  2,  3,  8,  18  and  19  are  used  to  support 
terminal  failure  analysis. 

c.  Mode  codes  3,  4  and  5  are  used  to  control  the  redundant 
buses. 

d.  Mode  codes  1,  16  and  17  are  used  in  asynchronous  bus 
operation . 

e.  Mode  codes  0,  6,  7,  20,  and  21  are  not  used. 

Table  6  indicates  which  mode  command  operations  are  required  in  a 
remote  device  to  make  it  compatible  with  the  DAIS  system  control  procedures 
and  master  executive. 

Table  7  shows  the  use  of  the  mode  commands  in  relationship  to  the 
system  control  functions. 

4.1.3  Application  Software  Executive  Services 

The  DAIS  Local  Executive  provides  certain  services  to  the  Applica¬ 
tion  Software.  It  defines  both  software  elements  and  real-time  statements. 

The  software  elements  allow  program  and  data  modules  to  be  classified  according 
to  their  function.  The  real-time  statements  operate  on  the  software  elements. 
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FIGURE  17.  ASYNCHRONOUS  MESSAGE  PROTOCOL  -  REMOTE  TERMINAL  REQUEST 


SERVICE  REQUEST  BIT 


Transmit  last  command  1  data  word,  TERM-TO-CONT  Last  valid  terminal  command 


MIL-STD-1553B  MODE  CODE  RELATIONSHIP  TO  SYSTEM  FUNCTIONS 


The  Application  Software  elements  which  ate  recognized  by  the  local 
executive  software  are  Tasks,  Coinsuhs,  Compool  Block:.,  and  ‘vents,  defied  as 
fol 1 ows : 


a.  Tasks  are  programs  or  processing  modules  which  can  either  te 
controllers  or  calculators.  Application  software  is  organized  in  tasks  (uro¬ 
gram  modules)  with  each  performing  a  function  as  required  for  the  specific 
system  application.  Each  task  contains  executable  code  and  local  data. 

b.  Comsubs  are  common  subroutines  which  differ  from  tasks  in  that 
they  are  required  to  be  re-entrant.  Comsubs  can  be  used  by  many  tasks,  so 
that  one  task  using  a  particular  comsub  can  bp  suspended  in  the  middle  of  the 
comsub  routine  by  another  task  using  the  same  comsub. 

c.  Compool  Blocks  provide  data  communication  between  tasks  and  the 
external  world  or  equipment.  A  buffer  system  is  provided  by  the  use  of  global 
copies  and  local  copies  to  prevent  a  compool  block  from  being  read  when  it  has 
been  partially  updated.  Every  task,  except  privileged  tasks,  interfaces  with 
a  local  copy  while  performing  its  calculations.  The  local  copy  is  updated 
from  the  global  copy  with  the  READ  statement;  the  local  copy  updates  the  globai 
copy  by  the  write  statement.  A  special  statement  (TRIGGER)  is  used  for  a 
critically  timed  compool  block. 

In  a  privileged  task,  communication  is  allowed  directly  with  the 
global  copy  in  the  processor  in  which  the  task  resides.  The  privileged  task 
cannot  be  interrupted  by  another  task  or  by  the  Executive. 

Since  the  READ,  WRITE,  and  TRIGGER  statements  invoke  Executive 
services  that  operate  in  the  Privileged  Mode,  this  guarantees  a  task  will  not 
reference  partially  updated  data. 

d.  Events  are  data  items  used  to  communicate  real-time  conditions 
signalled  by  a  process.  An  event  is  either  "ON"  or  "OFF". 

Real-time  statements  are  used  by  tasks  to  control  the  state  of  other 
tasks,  control  values  of  events,  and  control  reference  to  ccmpoo1  blocks.  The  • 
are  J73-defined  statements  which  the  application  programmer  uses  during  the 
ievelopment  of  mission  software  as  follows: 

Schedule  Statement 
Cancel  Statement 
Terminate  Statement 
Wait  Statement 
Signal  Statement 
Read  Statement 
Write  Statement 
Trigger  Statement 
Broadcast  Statement 

The  first  four  statements  are  used  to  control  task  states.  These  states  and 
the  method  of  transitioning  from  one  state  to  another  state  are  shown  in  Figure  20. 

a.  Schedule  Statement.  Schedule  statements  are  used  to  place  an 
uninvoked  task  into  an  invoked  state.  An  invoked  task  becomes  active  and 
dispatchable  when  the  required  event  conditions  are  satisfied.  An  invoked 
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WAIT  STATEMENT 


EVENT  OR  TIME 


WAITING 
(INVOKED  AND 
ACTIVE) 


FIGURE  20.  TASK  STATE  DIAGRAM 


task  is  placed  in  execution  by  the  Executive  if  it  has  the  highest  priority 
among  the  tasks  which  are  dispatchable. 

A  schedule  statement  includes  the  name  of  the  task  to  be  scheduled, 
the  mode  of  task  (privileged  or  normal),  priority  of  the  task,  and  event 
conditions  to  be  satisfied. 

b.  Cancel  Statement.  The  Cancel  Statement  is  used  by  one  task  to 
place  another  task  in  the  Uninvoked  State.  If  a  task  is  cancelled,  all  the 
lower  branches  or  sons  of  the  tasks  in  the  control  tree  structure  are  cancelled. 

c.  Terminate  Statement.  The  Terminate  Statement  is  used  by  one 
task  to  place  another  task  in  the  inactive,  but  invoked, state.  If  a  task  is 
terminated,  all  the  lower  branches  or  sons  of  the  tasks  in  the  control  tree 
structure  are  also  terminated. 

d.  Wait  Statement.  Wait  Statements  are  used  by  tasks  to  place 
themselves  into  the  Wait  State  pending  occurrence  of  one  of  the  following 
conditions: 

1.  Absolute  Time 

2.  Relative  Time 

3.  Latched  Event 

4.  Unlatched  Event 

For  the  latched  or  unlatched  events,  the  task  remains  in  the  Wait  State  until 
the  specific  I  event,  either  on  or  off,  occurs. 

e.  Signal  Statement.  Signal  Statements  are  used  by  tasks  to  set  a 
specified  event  to  a  specified  value,  either  on  or  off. 

f.  Read  Statement.  Read  Statements  are  used  by  tasks  to  copy  the 
values  of  specified  compool  blocks  (global  copies)  into  a  local  copy  to  be  use'" 
by  the  task. 

g.  Write  Statement.  Write  Statements  are  used  by  the  tasks  to  copy 
the  values  of  specified  locaT  copy  into  the  specified  compool  block  (global 
copy).  The  Write  Statement  causes  global  copies  in  other  processors  or  virtual 
copies  in  remote  terminals  to  be  updated  and  causes  signalling  of  an  event 
associated  with  the  compool  block. 

h.  Trigger  Statement.  The  Trigger  ^‘■at  'ts  are  used  by  a  task 

to  send  a  specified  critically-timed  compool  ' 'k  ‘a)  to  a  specified  remote 
terminal  at  a  specified  time.  This  causes  u  ■  "  cical ly-timed  asynchronous  bus 
message  operation  to  be  performed  where  the  local  copy  of  a  specified  compool 
block  is  sent  to  a  global  copy  in  the  Master  Processor  and  where,  at  the  speci¬ 
fied  time,  the  data  is  transmitted  to  the  specified  remote  terminal. 

i.  Broadcast  Statement.  The  Broadcast  Statement  is  used  only  by 

a  privileged  mode  task.  After  updating  a  global  copy  of  a  compool  block,  the 
broadcast  statement  is  used  to  cause  the  asynchronous  update  of  remote  and/or 
virtual  copies  of  the  compool  block. 
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4.1.4 


Error  and  Failure  Management 


Bus  message  error  management  and  terminal  failure  management  are 
performed  by  the  master  BCM  and  the  master  executive.  In  addition,  each 
terminal  on  the  multiplex  data  bus  provides  mechanisms  for  detecting  and 
recording  message  error  conditions  and  terminal  failures.  Message  error 
conditions  and  terminal  failure  conditions  are  recorded  in  the  Built-In-Test 
(BIT)  word  which  can  be  obtained  by  the  master  with  a  mode  command.  Also, 
each  terminal  records  in  a  register  (Last  Command)  the  last  valid  command 
received  by  that  terminal  which  also  can  be  obtained  by  the  master  with  a 
mode  command. 

The  master  executive  and  BCM  centrally  manage  the  message  protocol 
to  recover  from  message  errors  and  reconfigure  for  terminal  failures  via  the 
following  activities. 

a.  Monitor  the  message  sequence  to  determine  successful  or 
unsuccessful  completion. 

b.  Analyze  error  response  and  determine  type  of  retry 
procedure  for  unsuccessful  messages. 

c.  Perform  retry  of  unsuccessful  message,  first  on  the 
same  data  bus. 

d.  Analyze  error  response  if  not  successful  and  retry 
the  unsuccessful  message  on  redundant  data  bus. 

e.  Perform  failure  analysis  if  retry  of  message  on  alter¬ 
nate  bus  is  unsuccessful. 

f.  Update  the  system  configuration  tables  based  upon  the 
error  conditions  and  failures. 

The  remote  devices  on  the  multiplex  bus  collaborate  in  message  error 
detection  by  validating  each  receivecj  word.  A  word  is  invalid  if  it  contains: 

•  Parity  error 

•  Incorrect  or  missing  sync 

•  Incorrect  bit  count 

•  Invalid  Manchester  format 

A  remote  receiver  will  not  respond  with  a  status  word  after  detecting 
a  message  error.  As  message  data  is  received  by  a  BCM,  it  is  stored  in  the 
processor  memory  via  DMA.  If  received  unsuccessfully,  the  message  error  bit 
in  the  tag  word  is  set.  As  message  data  is  received  by  an  RT,  the  data  is 
temporarily  stored.  If  received  unsuccessfully,  the  data  is  not  transferred 
to  the  subsystems. 

Message  Error  analysis  and  retry  procedures  are  performed  by  the 
Master  Processor/BCM.  Error  analysis  is  based  on: 

•  The  bus  instruction  which  caused  the  message  to 
be  sent. 
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•  The  status  word(s)  received  from  the  transmitting 
and/or  receiving  terminal  involved  in  the  opera¬ 
tion,  and 

•  The  interrupt  code  register  (ICR)  and  internal  status 
register  (ISR)  in  the  Master  BCI. 

The  method  of  retry  is  based  on  specifications  Oi  the  system  designer, 
the  type  of  message  operation,  and  the  manner  in  which  the  error  is  detected. 

The  majority  of  messages  are  simply  retried  the  number  of  times  specified  in 
the  individual  bus  instruction,  and  then  if  necessary  retried  again  on  the 
redundant  multiplex  bus.  The  system  designer  may  specify  that  a  message  re¬ 
quires  a  careful  retry.  This  is  done  if  a  subsystem  would  be  degraded  or 
function  improperly  if  sent  repeated  data.  In  this  case,  the  message  error 
management  must  first  confirm  that  the  data  was  not  properly  received  befoi e 
repeating  the  message. 

The  type  of  message  operation  influences  the  message  error  management 
in  several  ways.  Synchronous  messages  may  normally  be  repeated  immediately.  A 
second  message  simply  overwrites  the  first  and  the  message  data  is  not  scheduled 
for  processing  until  a  later  minor  cycle  anyway.  If  one  assumes  that  the  source 
of  a  message  error  is  of  short  duration  and  occurs  randomly,  it  is  easy  to  see 
this  is  the  most  effective  approach.  The  BCI  can  recover  the  error  automatically 
and  an  interrupt  of  the  processor  is  not  even  required.  Asynchronous  messages 
to  a  remote  processor  require  careful  retry.  Such  messages  are  separately 
buffered  and  queued  as  received  and  thus  risk  duplication  if  repeated.  An 
asynchronous  message  from  a  remote  processor  can  be  retried  immediately  since 
the  remote  does  not  perform  buffer  management/queue  update  processing  until  after 
the  synchronize  mode  command  is  received. 

The  method  of  error  detection  is  principally  a  question  of  whether 
the  master  is  explicitly  aware  of  the  message  error.  This  is  the  case  when  a 
data  error  is  detected  while  the  master  is  receiving  data  (i.e.  RDE  indication 
in  a  terminal  to  controller  operation).  In  this  instance,  no  further  analysis 
is  needed.  When  the  primary  error  detection  is  by  a  remote  device,  the  situation 
is  less  clear.  In  accord  with  MIL-STD-1553B,  remote  devices,  upon  detecting  c.n 
error,  do  not  return  any  status.  Subsequent  mode  code  operations  are  necessary 
for  the  master  to  acquire  and  examine  the  status  word  associated  with  the  most 
recent  operation. 

However,  the  status  word  error  bits  in  the  ISR  do  not  necessarily 
imply  a  message  error.  They  indicate  the  absence  of  a  good  status,  which 
could  simply  mean  a  bus  error  occurred  during  the  transmission  of  the  status 
word  itself.  A  similar  result  occurs  if  a  bus  error  happens  during  the  trans¬ 
mission  of  a  command  word.  The  intended  terminal  will  not  respond  to  a  garbled 
command,  and  the  Master  BCI  will  set  the  status  error  bit  after  an  appropriate 
time  out.  But,  in  this  later  case,  note  that  the  status  word  contained  in  the 
remote  device  will  be  a  good  status  left  over  from  some  previous  message  opera¬ 
tion.  This  defines  the  need  for  the  last  command  sequence. 

It  is  to  be  recognized  that  the  last  command  register  is  maintained 
in  each  TCU  in  an  R.  and  is,  therefore,  bus-dependent.  The  mode  code  to  transmit 
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the  last  command  must  be  sent  on  the  same  bus  as  referenced  in  the  bus  instruc¬ 
tion  pair  for  that  RT.  Also,  the  Last  Command  register  is  updated  by  all 
commands  other  than  Transmit  Last  Command.  Therefore,  if  the  last  command  may 
be  required  for  error  analysis  it  must  be  retrieved  first. 

It  should  also  be  noted  that  the  technique  of  retrieving  the  last 
command  register  assumes  the  most  recent  successful  operation  was  not  an  iden¬ 
tical  (subaddress,  word  count,  transmi t/recei ve)  command.  Should  back-to-back 
identical  commands  be  possible,  (such  as  for  a  very  limited  use  RT),  the  system 
designer  is  responsible  for  seeing  that  intervening  commands  are  sent  to  permit 
the  correct  operation  of  the  retry  procedures.  Generally,  a  transmit  status  mode 
command  before  each  such  message  will  be  most  reliable. 

One  of  the  expected  sources  of  message  errors  is  that  a  remote  device 
will  occasionally  be  busy  when  commanded  to  transmit  or  receive  data.  A  busy 
transmitter  sends  no  data  and  a  busy  receiver  accepts  no  data,  so  duplicated 
messages  are  not  a  problem  and  no  confirmation  of  an  error  is  required.  A 
limple  retry  of  the  message  is  performed,  and  a  count  of  repeated  busy  responses 
on  a  single  message  is  maintained  to  prevent  an  infinite  loop. 

When  a  message  error  persists  after  the  specified  number  of  retries, 
the  error  is  logged  via  the  conf iguration  management  function  and  the  message 
s  switched  to  the  redundant  multiplex  bus.  Note  if  the  message  succeeds  on 
the  alternate  bus,  the  bus  operations  simply  continue  and  the  switched  message 
temains  on  the  alternate  bus.  Thus,  if  one  bus  side  of  a  terminal  is  operating 
n  a  marginal  fashion,  messages  will  migrate  to  the  good  bus  side  as  errors  are 
e  ncountered. 

An  auxiliary  function  imposed  on  the  message  retry  procedure  is  that 
of  NO-OPing  messages  after  a  terminal  has  been  declared  failed.  When  a  terminal 
is  failed  (a  decision  made  by  the  configuration  management  function)  no  attempt 
is  made  to  remove  the  instructions  addressing  the  terminal  from  all  bus  lists. 

That  would  require  an  extensive  search  operation  or  some  pointer  lists  to  locate 
all  the  affected  bus  instructions.  Performing  the  NO-OP  in  the  retry  procedure 
distributes  the  impact  of  removing  a  terminal's  messages  at  the  cost  of  an 
interrupt  per  message.  It  is  also  worth  noting  that  the  NO-OPing  procedure  's 
opera tiona 1 ly  almost  identical  to  switching  a  message  to  the  redundant  bus. 

4.1.5  Configuration  Management 

The  repeated  failure  of  a  bus  message  is  reported  to  the  Configuration 
Management  function  for  tabulation  and  analysis.  A  message  which  succeeds  on 
immediate  retry  is  not  reported.  (In  fact,  the  processor  is  not  even  aware  of 
the  error  if  an  automatic  retry  succeeds.)  Reported  errors  are  tabulated  against 
a  terminal  address  with  separate  counters  accumulating  errors  on  the  two  redundant 
communications  paths. 

The  overall  interaction  of  the  assorted  system  functions  involved  in 
declaring  or  responding  to  a  device  failure  is  shown  in  simplified  form  in 
Figure  Z\.  Configuration  Management  is  notified  only  after  repeated  errors 
and  then  a  failure  is  declared  only  after  a  critical  threshold  is  reached  or 
self  tests  reveal  a  hard  failure. 
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FIGURE  ?\.  CONFIGURATION  MANAGEMENT  INTERACTIONS 


The  first  task  of  Configuration  Management  is  to  decide  what 
terminal  to  charge  with  the  error.  While  determination  that  an  error  occurred 
is  primarily  based  on  the  receiver's  status  word  (or  lack  of  it),  the  error 
is  normally  attributed  to  the  transmitting  terminal.  The  receiver  is  charged 
with  the  error  only  in  the  case  that  he  reports  an  error  when  neither  the 
Master  processor/BCM  nor  the  transmitting  terminal  detect  any  anomaly. 

Error  counters  are  maintained  by  Configuration  Management  for  each 
bus  side  of  each  terminal  address.  Each  time  an  error  is  logged  against  the 
terminal  and  bus  side  the  counter  is  incremented  and  compared  to  a  user-defined 
threshold. 


When  the  error  count  reaches  this  threshold,  the  bus  side  is  flagged 
as  "suspect"  for  this  terminal  address.  Once  a  bus  side  is  flagged  as  suspect, 
the  message  retry  procedures  will  no  longer  switch  messages  to  this  bus  for 
this  terminal.  If  the  threshold  is  reached  for  both  sides  of  a  terminal,  the 
terminal  is  reinitialized  in  an  attempt  to  restore  normal  operating  character- 
i  sties. 


The  reinitialization  procedure  is  represented  in  Figure  22  and  con¬ 
sists  of  a  series  of  mode  commands  to  reinitialize,  perform  self  test  and 
transmit  the  BIT  word.  The  BIT  word  format  for  an  RT  is  shown  in  Figure  23. 

As  may  be  seen,  the  terminal  is  capable  of  detecting  a  variety  of  internal 
problems.  The  sequence  of  initialize  and  perform  self  tests  primarily  exercises 
the  TCU  and  MTU  functions.  (The  individual  IM's  and  channels  are  tested  in 
background  of  normal  operations  after  being  accessed  for  data.) 

The  reinitialize  function  will  analyze  the  BIT  word  retrieved  and 
flag  each  bus  as  good  or  failed  and  report  back  to  configuration  management. 
Should  any  errors  occur  in  these  mode  code  operations,  this  will  be  considered 
an  indication  of  failure,  of  the  bus  side  of  that  terminal. 

When  a  good  bus  indication  is  returned  to  configuration  management, 
the  terminal  will  be  considered  operable  on  that  bus.  The  appropriate  error 
counter  and  "suspect"  flag  will  be  cleared  and  normal  communication  witn  the 
terminal  will  be  resumed.  Should  the  error  counters  again  reach  the  thresholds, 
the  whole  sequence  will  be  repeated.  To  protect  itself  from  excessive  overhead, 
the  system  will  keep  count  of  the  number  of  times  a  terminal  has  been  reinitial¬ 
ized.  If  this  count  reaches  a  user-defined  limit,  the  terminal  will  be  flagged 
as  failed. 


DAIS  has  not  implemented  any  recovery  procedures  for  failed  RTs.  Once 
a  termir  '  is  flagged  as  failed,  messages  to  that  terminal  are  NO-OPed  as  errors 
are  enco  red  and  all  communication  with  the  RT  ceases.  Message  traffic  is 
restored  only  by  a  system  reload  and  cold  initialization. 

Message  errors  which  are  attributed  to  a  remote  processor  will  be 
counted  aqainst  each  bus  side  and  the  count  compared  to  a  threshold  as  des¬ 
cribed  above.  One  bus  side  may  be  flagged  as  "suspect"  and  message  traffic 
will  migrate  to  the  other  bus.  Flowever,  if  a  remote  processor  becomes  suspect 
on  both  buses,  it  is  failed  immediately  and  the  startup/restart  function  is 
i nvoked . 
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FIGURE  22.  REINITIALIZE  RT 
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FIGURE  23.  BUILT-IN-TEST  (BIT)  WORD 


The  DAIS  executive  software  architecture  (a  virtual  memory  apyiojuni 
does  not  permit  continued  operation  in  the  event  of  a  processor  failure.  A 
reinitialization  sequence  is  not  done  for  processors  since  the  startup/restar t 
function  provides  a  more  comprehensive  verification  of  both  hardware  and  soft¬ 
ware  and, in  the  event  of  a  solid  failure,  gives  the  pilot  better  visibility 
into  what  equipment  is  operable,  thereby  facilitating  reconf iguration. 

In  addition  to  error  reports  from  message  retry,  the  configuration 
management  function  may  receive  failure  reports  from  the  status  exception/BIT 
word  analysis  function.  This  function  is  invoked  when  a  status  word  returned 
during  a  message  operation  contains  an  exception  condition  other  than  M/E, 

SR,  or  busy.  The  exception  is  normally  indicated  by  the  T/F  bit  (devices  with 
other  exception  indicators  are  known  as  "strangers")  and  more  detailed  informa¬ 
tion  is  contained  in  the  BIT  word. 

The  BIT  word  format  for  a  BCM  is  shown  in  Figure  24.  Since  self 
tests  are  not  performed  for  BCMs  during  normal  operation,  the  power-on-reset 
is  the  only  condition  that  will  cause  a  T/F  bit  to  be  set  for  a  remote  pro¬ 
cessor.  This  is  treated  as  a  fatal  condition  and  the  processor  failed  immedi¬ 
ately.  In  practice,  this  will  not  occur,  since  the  loss  of  power  by  a  remote 
will  result  in  accumulated  message  errors  and  the  recovery  of  power  will  cause 
the  processor  to  cycle  through  the  startup/loader  which  clear',  the  BIT  register 
prior  to  enabling  for  remote  communications. 

The  flow  of  the  status  exception/BIT  word  analysis  is  shown  m  Figur* 
25.  When  the  exception  is  from  an  RT,  the  BIT  word  is  retrieved  for  analysis. 
Either  a  bus  side  (MTU  or  TCU)  failure  is  reported  or  an  IM/:hannel  failure 
is  reported  to  configuration  management.  The  IM/channel  failures  are  separatel 
counted  for  information  purposes,  but  otherwise  either  exception  is  cleared  by 
reinitializing  the  terminal.  Again,  an  excessive  number  of  initializations  wil 
result  in  terminal  failure. 

When  an  entire  device  is  flagged  as  failed,  Configuration  Miraseneot 
will  perform  one  of  several  actions  dependin';  on  tie  type  of  device.  If  a 
remote  terminal  is  failed.  Mission  Application  Software  will  be  notified  by 
way  of  the  Subsystem  Status  Monitor,  so  that  appropriate  action  -nay  be  initial' 

When  any  processor  fails,  configuration  management  invokes  the  system 
startup  procedures  and  all  processors  perform  hardware  and  software  tests  to 
determine  operability.  Outputs  to  the  PCP/ACr  lights  advise  the  pilot  of  the 
hardware/sof tware  status. 

Note  that  DAIS  has  not  implemented  a  Monitor  function.  Should  the 
Master  fail  in  such  a  way  that  the  above  functions  cannot  be  performed,  the 
system  will  freeze  and  manual  intervention  by  the  pilot  is  required. 

4.2  DAIS  Architecture  Features 

The  DAIS  architecture  possesses  specific  characteristics  which  faci¬ 
litate  the  adapability  of  the  system  to  various  applications  and  support  effec¬ 
tive  incremental  integration  and  test  of  the  DAIS  core  elements.  These  key 
characteristics  are  discussed  in  the  following  sections. 
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FIGURE  25.  STATUS  EXCEPTION/BIT  WORD  ANALYSIS 
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Specific  features  in  the  DAIS  system  which  allow  adaptation  of  the 
core  elements  to  a  specific  avionics  system  configuration  are  presented  below. 

4.2.1  Bus  Devices 

The  basic  message  structure,  data  format,  and  command-response  pro¬ 
tocol  required  for  the  multiplex  system  is  described  in  Section  4.1.2.  The 
message  protocol  is  defined  as  that  sequence  of  bus  messages  required  to  per¬ 
form  normal  multiplex  synchronous  and  asynchronous  operations  and  to  support  the 
message  error  detection  and  recovery  process.  The  MIL-STD-1553B  definition  of 
the  command  format  allows  up  to  32  different  addressed  devices  to  be  ,impl emented 
on  the  multiplex  system.  DAIS  has  restricted  this  definition  to  allow  up  to 
four  processors/BCMs  and  28  remote  terminal  devices. 

The  system  designer  defines  the  specific  configuration  (number  of 
processors/BCMs,  number  of  RTs  to  interface  with  the  avionic  sensors,  and  sub- 
■ystems  using  the  standard  Interface  Modules  ( I Ms )  or  unique  IMs  if  required), 
he  system  designer  then  defines  the  sensor  inputs/outputs  as  data  bus  messages 
.  nd  inputs  this  information  to  PALEFAC.  PALEFAC  generates  the  Executive  bus 
nstruction  list  tables  accordingly.  This  directs  the  messages  to  the  proper 
l  rocessor  containing  the  application  software  (e.g.  EQUIPS  module)  which  pro¬ 
cesses  the  sensor/subsystem  data. 

The  DAIS  architecture  is  readily  adaptable  to  various  numbers  of 
devices  on  the  bus.  It  provides  the  tools  to  automatically  general-*  and 
direct  the  messages  to  the  proper  application  software  in  one  of  the 
processors . 

4.2.2  Processor/bus  Control lers 

The  architecture  provides  the  capability  to  expand  or  reduce  the 
number  of  processors/BC Is  fora  specific  application.  The  system  desiyner 
considers  trade-offs  in  determining  the  number  of  processors/BCIs  required. 
Mission  requirements,  reliability  and  availability  must  be  considered. 

The  system  designer  defines  the  Mission  Software  application 
modules  based  upon  tne  mission  requirements  and  avionic  suite.  The  applica¬ 
tion  programmer  develops  the  application  modules  using  the  J73  language  and 
mission  software  standards.  Based  upon  the  application  execution  times, 
memory  swe,  data  access,  comsubs,  and  the  bus  message  traffic,  the  system 
designer  then  partitions  the  application  tasks  among  the  processors  using 
PALEFAC.  PALEFAC  produces  the  tables  required  for  run  time  execution  of  the 
application  software  in  the  specific  configuration  of  processors/bus  con¬ 
trollers.  These  tables  are  used  by  the  master  executive  and  the  local 
executive. 

4.2.3  Remote  Terminal  (RT)/lnterface  Modules  (IMs) 

The  RT  has  a  modular  and  programmable  design.  This  allows  flexible 
partitioning  of  the  data  messages  to  the  appropriate  sensors/subsystems  and 
signal  conditioning  required  by  different  numbers  and  mixes  of  subsystem 
signals.  This  is  accomplished  as  follows: 
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The  Timing  and  Control  Unit  (TLU)  in  the  RT  performs  ail  of  the 
timing,  control,  buffering,  decoding,  and  checking  required  to  receive  nr 
transmit  information  from  the  data  bus  and  transfer  that  information  as 
outputs  or  inputs  from  the  RT  via  the  Interface  Modules  (IM).  The  TCU  con¬ 
tains  a  programmable  device  which  controls  the  mapping  of  each  data  word  in 
the  RT.  The  interface  between  the  TCU  and  IMs  is  standardized  and  contains 
the  signals  required  to  allow  TCU  to  select  the  individual  modules.  There¬ 
fore,  all  IM  slots  can  accept  all  IM  types. 

Each  RT  will  interface  with  different  numbers  and  mixes  of  sensor/ 
subsystem  signals  for  each  specific  system  configuration.  This  is  accom¬ 
plished  by  inserting  the  proper  number  and  type  of  interface  modules  into 
the  IM  slots  in  the  RT  housing  and  by  programming  the  ROM  in  the  TCU.  If 
required,  a  special  interface  module  can  be  designed  to  interface  with  an 
existing  subsystem  having  a  unique  interface. 

The  functions  of  the  RT  can  also  be  embedded  in  a  sensor  or  sub¬ 
system  so  that  the  interface  of  the  sensor  or  subsystem  is  directly  with 
the  multiplex  data  bus.  Functional ly.  the  embedded  RT  responds  to  commands 
received  on  either  data  bus  in  the  same  w \y  as  an  RT. 

4.2.4  Application  Software 

The  UAIS  System  Architecture  is  designed  to  allow  modular  imple¬ 
mentation  of  specific  systems  1,  us  r  .  the  required  elements  of  the  DAIS 
system,  both  hardware  and  software.  fi>st,  the  set  of  multiplex  equipment 
for  interfacing  to  the  external  world  (sensors  and  Controls  and  Displays 
equipment)  nmst  be  chosen.  Then,  the  design  of  the  processing  syste"  can 
begin.  The  Application  Software  is  initially  designed  as  if  it  will  exist 
in  one  large  virtual  processor.  This  virtual  processor  has  as  much  memory 
space  and  execution  time  available  as  the  sum  of  the  flight  processors  to 
actually  be  used  in  the  system.  After  the  data  interfaces  have  been  defined 
t>  tne  outside  world  ( •  u  1  tiple*  bus  e. sales,  and  the  functional  pe*'f  orm-i”  :e 
’Cquired  of  the  application  software  has  beer,  identified,  the  layout  of 
>.c. spool  Blocks  and  Tasks  can  begin. 

lompool  Blocks  are  the  data  communication  paths  between  the  appli¬ 
cation  software  and  the  external  world  and  among  the  application  software 
tasks.  Tasks  are  the  processing  elements  in  the  application  software  which 
collectively  perform  the  avionics  processing  function.  Tasks  access  the  Corn- 
poo)  Blocks  through  calls  upon  Executive  services  (such  as  READ  and  WRITE) 
and  operate  upon  the  contents  of  the  Con. pool  Blocks  for  processing  purposes. 

After  the  functions  of  the  application  system  have  been  designed 
in  terms  of  Tasks  and  Compool  Blocks,  and  the  Application  Software  has  been 
tested  on  the  host  processor,  partitioning  of  the  application  system  onto  the 
flight  processors  begins.  This  partitioning  is  illustrated  in  Figures  26  and 
27  for  a  two  and  three  processor  system  configuration,  respectively. 

The  application  software  can  be  easily  partitioned  across  a  set  of 
flight  processors  by  using  the  DAIS  Executive  and  PALEFAC.  The  DAIS  Executive 
provides  general  I/O  control  for  all  communications  on  the  multiplex  bus 
{between  processors  and  to  the  external  world).  PALEFAC  builds  the  data  base 
which  is  then  used  by  the  Executive  to  control  system  communications. 
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MISSION  SOFTWARE  PARTITIONING  - 


FIGURE  27.  MISSION  SOFTWARE  PARTITIONING  -  THREE  PROCESSORS 
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The  use  of  the  Executive  and  PALEFAC  results  in  an  automatic  parti¬ 
tioning  of  the  Compool  Blocks  onto  processors  based  upon  the  partitioning  of 
Tasks  and  upon  which  Tasks  use  which  Compool  Blocks.  If  a  Compool  Block  is 
used  for  communications  between  tasks  and  if  the  tasks  are  split  into  two  or 
more  processors,  the  system  will  automatically  generate  a  copy  of  the  Compool 
Block  at  each  processor;  it  will  also  generate  the  multiplex  bus  message  to 
update  all  other  copies  when  one  copy  is  updated. 

The  system  will  also  automatically  generate  the  multiplex  bus 
messages  required  to  connect  the  Compool  Blocks  to  the  devices  on  the  multi¬ 
plex  bus.  All  multiplex  bus  messages  may  be  declared  as  synchronous  with  a 
period  and  phase.  If  not  so  specified,  the  system  will  automatically  generate 
asynchronous  updates  of  the  bus  messages  when  a  copy  is  updated. 

4.2.5  Interface  Standards 

The  DAIS  was  converted  from  MIL-STD-1553A  to  MIL-STD-1553B. 

4.2.5. 1  DA  IS/ 1 55  3B  Message  Protocol 

As  discussed  previously,  MIL-STD-1553B  defines  the  basic  message 
structure  and  command-response  protocol.  In  order  to  properly  handle  detected 
message  errors  and  other  DAIS  system  features,  DAIS  developed  a  set  of  proce¬ 
dures  that  define  bus  operations  and  message  error  and  terminal  failure 
detection  and  recovery  processes.  If  a  sensor/subsystem  device's  bus  interface 
conforms  to  this  composite  DAIS/1553B  protocol,  it  would  be  fully  compatible 
with  the  DAIS  System  Architecture. 

4.2.6  Portabil ity 

The  DAIS  Mission  Software  has,  from  the  very  beginning,  been  con¬ 
ceived  as  an  easily  retargetable  system.  The  single  most  important  feature 
that  allows  this  capability  is  the  development  of  more  than  97?  of  the  DAIS 
Executive  Software  in  JOVIAL  J73  (The  only  routines  written  in  assembly 
language  are  processor-dependent  I/O  operations,  register  manipulation  opera¬ 
tions  and  lowest  level  interrupt  handlers).  All  of  the  DAIS  Application 
Software  is  implemented  in  JOVIAL  J73.  A  striking  demonstration  of  the  porta¬ 
bility  of  the  DAIS  Mission  Software  is  the  fact  that  it  executes  both  on  the 
DAIS  processor  ana  on  the  DECsystem-10,  the  host  processor  facility.  In  fact, 
stand-alone  module  testing  and  initial  subsystem  integration  testing  of  Appli¬ 
cation  Software  is  performed  on  the  host  processor.  This  is  possible  since 
the  JOVIAL  J73  Compiler  has  a  code  generator  for  both  the  DECsystem-10  and 
the  DAIS  processor,  which  points  out  the  ease  of  retargetabi 1 i ty  of  the  DAIS 
Software  System. 

4.2.7  Redundancy 

DAIS  provides  redundancy  in  the  system  architecture.  This  can  be 
employed  to  provide  backup  and  recovery  to  complete  mission  functions  in 
spite  of  hardware  failure.  The  areas  which  can  be  used  for  redundancy  are: 

a.  Dual  redundant  data  bus  includes  redundant  bus 
interface  modules  in  the  BCIU  and  RT. 
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b.  System  can  employ  dual  redundant  RTr  'or  a  saeci‘u 
subsystem. 

c.  Multifunction  keyboard  and  associated  Data  Entry 
Keyboard  can  be  used  as  a  backup  to  the  Integrated 
Multifunction  Keyboard  and  associated  Data  Entry 
Keyboard. 

d.  Raster  displays  can  serve  as  backup  to  each  othe>'. 
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SUPPORT  FACILITY 


The  purpose  of  the  AVSAIL  support  facility  is  to  test  and  evaluate 
the  DAIS  core  element  architecture  and  a  representati ve  set  of  sensor^/subsys terns. 
The  support  facility  provides  a  real-time  simulation  of  a  military  aircraft 
performing  an  operational  mission.  The  simulation  generates  the  interface 
signals  between  the  simulated  aircraft  sensor  suite  and  the  DAIS  system.  The 
avionic  equipment  is  thus  subjected  to  a  data  signal  environment  which  is 
nearly  identical  to  actual  flight.  A  simulated  cockpit  is  included  as  part 
of  the  simulation  for  realistic  evaluation  of  the  avionic  system. 

The  support  facility  for  DAIS  consists  of  a  Software  Test  Stand 
(STS)  and  an  Integrated  Test  Bed  (ITS).  Initially,  the  Software  Test  Stand 
provided  a  capability  to  test  the  mission  software  resident  in  the  DAIS 
flight  processors  (AN/AYK-15).  The  Integrated  Test  Bed  provided  the  capability 
to  test  the  DAIS  core  elements  which  included  the  mission  software,  the  DAIS 
processors  (AN/AYK-15),  the  multiplex  bus  system  (MIL-STD- 1553A)  and  the 
cockpit  controls  and  displays.  Currently,  both  the  STS  and  ITB  use  a  MIL-STD- 
1553B  multiplex  bus  system.  The  flight  processors  have  been  changed  to  the 
AN/AYK-15As  on  the  STS  only.  Therefore,  the  STS  provides  the  capability  to 
test  the  DAIS  core  elements  which  include  new  mission  software,  the  DAIS 
AN/AYK-15A  processors,  the  MIL-STD- 1 553B  multiplex  bus  system  and  the  cockpit 
controls  and  displays.  The  ITB's  flight  processors  are  still  the  AN/AYK-15s, 
so  the  ITB  is  used  for  testing  hardware  and  running  simulations.  Both  the 
STS  and  1TB  utilize  a  complex  of  digital  computers  consisting  of  a  Digital 
Equipment  Corporation  (DEC)  DECsystem-10  and  a  number  of  DEC  PDP  11  series 
computers . 


Simulation  software  resident  in  the  DECsystem-10  was  developed  to 
provide  real-time  simulation  of  a  military  aircraft  in  an  operational  environ¬ 
ment.  The  aircraft  dynamics,  the  aircraft  sensors  and  weapon  targets  are 
simulated.  The  simulation  is  driven  from  the  cockpit  by  an  operator  acting 
as  a  pilot.  The  simulated  cockpit  is  equipped  with  Controls  and  Displays  so 
that  the  various  modes  of  a  mission  may  be  flown  by  the  pilot  with  an  out-the- 
window  background  scene. 

The  support  hardware  and  software  provides  interfaces  between  the 
DAIS  elements  under  test  and  the  host  simulation  software.  The  support 
facility  provides  the  capability  to  set  up  a  test,  conduct  a  simulation,  and 
record  data  from  both  the  DAIS  elements  and  the  simulation.  During  a  simula¬ 
tion,  sufficient  test  data  is  displayed  in  real-time  to  indicate  that  the 
system  is  operating  satisfactorily.  It  provides  presentation  of  test  results 
for  observing  systems  performance. 

The  support  facility  is  composed  of: 

1.  STS  Support  Hardware 

2.  STS  Support  Software  and  PDP-11  Processors 

3.  ITB  Support  Hardware 

4.  ITB  Support  Software  and  PDP-11  Processors 

5.  Host  Simulation  Processor,  DECsystem-10 

6.  Simulation  Software 

7.  System  Test  Software 

8.  Picture  System 

9.  Picture  System  Software 
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5.  1 

The  initial  support  lability  functions  i  ai-iurcim  is.  shown  H  ■.»«• 
2b.  It  consists  of  STS  &  1TB  hardware  arid  software  both  sharing  tin  :-os ' 
Simulation  Processor  and  the  DAIS  cockpit.  The  current  support  facility 
functional  diagram  is  shown  in  t  igure  29.  Support  software  is  re  icerit  r 
trie  DECsystem- 10  and  in  the  POP- 11  Processors. 

5.1.1  I ntegrated  Tes _t  Bed  j  1 T B_) 

The  Integrated  Test  Bed  UTB;  block  diagram  is  shown  in  figure 
It  is  composed  of  the  support  facility  arid  DAI.  core  elements.  The  su|»pc  t 
facility  simulates  all  the  equipment  and  environment  external  tc  tne  DAI 
processor  using  the  resident  rissiori  software,  DAIS  rultiplex  systen  .  and 
DAIS  controls  and  displays.  The  ITB  support  facility  is  composed  of  support, 
hardware,  support  software  resident  in  the  PDP-11  processor,  the  simulation 
software  resident  in  the  host  simulation  processor,  the  DAIS  simulated  ccckp 
and  an  out-the-wi ndow  picture  system. 

The  support  hardware  provides  the  interfaces  between  the  simulate: 
and  the  DAIS  core  elements.  The  interface  includes:  Ij  the  multiple-  bis 
messages  which  drive  the  mission  software,  ?)  the  performance  coni  toning  c ; 
the  multiplex  bus  traffic  and  the  internal  operation  of  tne  H  ;sion  software- 
in  the  DAIS  processors,  5)  the  cockpit  controls  and  backup  instruments,  a-’d 
4)  tne  out-the-wi ndow  picture. 

The  support  software  controls  and  manages  the  support  hardware  arc 
provides  the  means  to  link  the  DtCsystem- 1 0  simulation  software  with  the 
DAIS  elements.  The  support  software  also  provides  the  performance  monitor 
and  control  functions  winch  are  related  to  test  set-up,  contiol,  3 no  data 
collection  for  post-test  analysis. 

The  host  simulation  processor  is  a  commercial  DTC syste ' - 1 L)  complex 
The  simulation  software  generates  the  rea1  world  environment  extern-  " 

CAIS  processors  f n  real  time.  The  simulation  it  driven  by  the  DAIS  coiA  •  t 
flight  controls  so  that  an  operator  tan  tlv  tne  simulation. 

An  out-the-wi ndow  picture  system  provides  a  symbolic  background 
scene  outside  of  the  cockpit  so  that  the  pilot  operator  will  expedience  the 
visual  orientation  of  flight  with  respect  to  IT's,  targets  and  runways.  The 
picture  system  also  provides  the  option  for  dis  laying  the  HUD  symbology 
uverlayed  on  the  background  scene. 

A  pictorial  representation  of  1TB  is  shown  in  Figure 

A  set  of  system  : <=> s t.  software  is  resident  in  the  host  simulation 
processors,  the  ITB  PDP-11  processors,  and  the  DAIS  processors.  It  performs 
the  system  readiness  test  prior  to  performing  operational  runs  and  diagnosin 
faul ts . 

5.1.2  So  f  twar  e  _T  e _s  t  St  a  nd_  ( 3  T  S ) 

A  block  diagnm  of  the  initial  STS  is  shown  in  Figure  32.  The  r,; 
system  was  similar  in  structure  to  the  ITB.  It  shared  lit1 1  i  znt  io"  .. 4  *  'v 
DAIS  cockpit  and  controls  -no  -Hs-i  iy*. .  and  real  -  ti-e  rvulatie1'  so*  tw  t*-. 
the  DECsystem- 10  complex.  Common  support  hardw,e-r  ,♦  two*-.  w  .  • 
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FIGURE  28.  INITIAL  SUPPORT  FACILITY  FUNCTIONAL  DIAGRAM 
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32.  INITIAL  SOFTWARE  TEST  STAND  (STS)  FUNCTIONAL  BLOCK  DIAGRAM 


both  ITB  and  STS.  The  initial  STS  was  generally  utilized  to  test  Mission 
Software  and  the  support  software  when  operation  with  the  real-time  siru  i- 
tion  models  and  DAIS  cockpit  was  not  required. 

A  block  diagram  of  the  current  STS  is  shown  in  figure  3..  The 
current  STS  and  the  initial  STS  have  the  following  differences: 

a.  Tne  multiplex  bus  system  was  changed  from  MIL-STD- 
1553A  to  MIL-STD- 1553B. 

b.  The  flight  processors  were  changed  from  AN/AYK-!5s 
to  AN/AYK-15AS. 

c.  The  SCADUs  were  replaced  by  the  PMIUs. 

d.  The  C I  Us  were  eliminated. 

5.1.3  Physical  Conf iguration 

The  support  facility  is  configured  as  laboratory  equipment.  The 
floor  layout  and  rack/console  configuration  for  STS  and  1TB  are  shown  as 
fol 1 ows : 

a.  Initial  STS/ITB  Floor  Layout  -  Figure  34 

b.  Current  STS/ITB  Floor  Layout  -  Figure  35 

c.  Initial  STS  Test  Control  Center  -  Figure  36 

d.  Current  STS  Test  Control  Center  -  Figure  37 

e.  Initial  STS  Equipment  Racks  -  Figure  38 

f.  Current  STS  Equipment  Racks  -  Figure  39 

g.  ITB  Test  Control  Center  -  Figure  40 

h.  Initial  ITB  Equipment  Racks  -  Figure  41 

i.  Current  ITB  Equipment  Racks  -  Figure  42 

5.2  I TB  Support  Hardware 

The  ITB  hardware  consists  of  the  following  subsystems: 

5.2.1  Universal  Remote  Terminal 

The  Universal  Remote  Terminal  (URT)  simulates  the  operation  of  a 
set  of  up  to  32  remote  terminals.  The  URT  receives  or  transmits  data  between 
the  DAIS  multiplex  data  bus  and  the  PDP  11/40  processor.  The  URT  provides  the 
same  interface  to  the  DAIS  multiplex  as  a  Remote  Terminal,  except  the  URT 
simulates  up  to  32  RTs. 

The  URT  is  set  up  and  contro^ed  by  the  SSDr:  software  in  the  PDP 
11/40  by  loading  the  URT  registers  and  RAMs.  In  real-time  operation,  the  URT 
performs  the  following: 


MuW II  Ok 


GURE  33.  CURRENT  SOFTWARE  TEST  STAND  (STS)  FUNCTIONAL  BLOCK  DIAGRAM 


o 


FIGURE  36.  INITIAL  SOFTWARE  TFST  STAND  TEST  CONTROL  CENTER 


FIGURE  37.  CURRENT  SOFTWARE  TEST  STAND 
(STS)  TEST  CONTROL  CENTER 
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NTEGRATED  TEST  BED  EQUIPMENT  RACKS 
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!IGURE  4Z.  CURRENT  INTEGRATED  TEST  BED  EQUIPMENT  RACKS 


1  Transfers  the  DAIS  multiplex  data  to/from  the  POP  11 
for  each  message  operation  (control ler-to-terminal , 
terminal -to- terminal ,  and  terminal -to-control ler) 
based  upon: 

•  RT  address/subaddress 

•  Transmi t/ receive  bit 

•  Word  count 

•  POP  11  memory  address 

2.  Responds  to  mode  commands  received  on  the  DAIS  multiplex 
data  bus.  The  URT  has  the  capability  to  generate  an 
interrupt  to  the  PDP-11  upon  receiving  the  following 
mode  commands: 

•  MIL-STD-1553A 

•  MTU1  or  2  shutdown 

•  MTU1  or  2  shutdown  override 

•  Reset  BIT  word 

•  Initialize  terminal 

•  Initiate  serial  channel  I/O 

•  Minor  cycle  sync 

•  MIL-STD- 1553B 

•  Synchronize  (with  and  without  data  word) 

•  Transmit  status 

•  Transmitter  shutdown 

•  Override  transmitter  shutdown 
4  Reset  remote  terminal 

•  Transmit  vector  word 

•  Transmit  last  command 

•  Transmit  BIT  word 

3.  Provides  the  capability  to  set/reset  bits  in  the 
serial  channel  activity  register,  module  error 
register,  and  the  BIT  register  for  each  simulated  RT. 

4.  Provides  the  capability  to  inhibit  the  status  response 
to  any  receive  command. 

5.2.2  Bus  Monitor  Unit 

The  Bus  Monitor  Unit  (BMU)  receives,  records,  and  breakpoints  on 
selected  messages  received  on  the  DAIS  multiplex  data  bus.  The  BMU  stores  the 
received  messages  into  the  PDP-11/40.  The  BMU  interfaces  with  the  DAIS  multi¬ 
plex  data  bus  and  monitors  for  data  messages  (control ler-to-terminal ,  terminal- 
to-control ler ,  and  terminal -to-terminal  messages)  and  mode  commands.  The  BMU 
operates  in  either  the  automatic  mode  or  manual  mode. 

The  BMU  is  set  up  and  controlled  by  the  PMC  or  the  PMIU  software 
in  the  PDP-11/40.  The  BMU  has  the  capability  to  provide  selective  monitoring 
as  follows: 


1.  Record  the  bus  traffic  beginning  at  a  specified 
breakpoint  and  record  for  a  specific  number  uf  w/  . 

2.  Record  the  bus  traffic  beginning  at  a  specified 
breakpoint  and  record  for  a  specified  length  of  t.’n-e. 

3.  Record  the  bus  traffic  beginning  at  a  specified 
breakpoint  and  record  until  a  second  specified 
breakpoint  is  reached. 

4.  Record  the  bus  traffic  beginning  at  a  specified 
breakpoint  and  record  only  a  specified  'essage. 

5.  Record  all  bus  traffic,  only  the  control  words 
(command  and  status),  or  only  the  data  wore,. 


G.  Transmit  a  message. 


The  BMU  also  has  a  manual  control  function  which  can  record  all 
bus  traffic,  only  the  control  words  (commana  and  status),  only  the  data 
words,  or  only  the  message  gap  time.  The  manual  modes  are  controlled  cirt-v.fl;. 
from  the  BMU  front  panel. 


5.2.3  Console  Intel  1 iqence  Uni t 

The  Console  Intelligence  Unit  (CIU)  operates  in  conjunction  with 
a  KS- 232  interface  with  the  PMC  PDP-11/40,  DECsystem-10,  and  the  Hazeltine 
terminals.  It  provides  the  means  to  control  and  load/change  DAIS  processor 
registers  and  memory.  The  CIU  is  supplied  by  the  DAIS  processor  vendor  to  sup 
port  the  debug  and  test  of  the  mission  software  under  non-rea  1  -  tire  conditions 
The  functions  the  user  is  able  to  perform  are: 


1. 

Clear  Processor 

10. 

Clear  Breakpoints 

2. 

Hal t  Processor 

11. 

Set  a  Breakpoint 

3. 

Toggle  Memory  Protect 

12. 

Step  Processor 

4. 

Read  Instruction  Counter 

13. 

Execute  Processor 

5. 

Load  Instruction  Counter 

14. 

Load  Tape  Image 

6. 

Read  Register 

15. 

Write  Tape  Image 

7. 

Load  Register 

16. 

Stutter  Mode 

8. 

Read  Memory 

17. 

DEC  to  Cassette 

9. 

Load  Memory 

18. 

Cass-.tte  to  DEC 

In  the  local  mode,  console  commands  are  issued  from  the  Hazeltine  keyboard. 
When  under  control  of  the  DECsystem-10  or  PMC  PDP-11/40,  the  CIU  is  in  the 
remote  mode.  The  DECsystem-10  or  PMC  PDP-11/40  functionally  interfaces 
with  the  CIU  similarly  to  the  Hazeltine  terminals.  This  allows  the  Hazeltine 
terminal  functions  to  be  performed  at  the  DECsystem-10  for  loading,  or 
PDP  11/40  under  PMC  software  control. 

5.2.4  Hazeltine  Terminals 

The  Hazeltine  terminals,  in  conjunction  with  the  Console  Intelli¬ 
gence  Unit  (CIU)  provide  interactive  control  of  the  DAIS  processor  registers 
and  memory  as  specified  above.  The  Hazeltine  terminals  include  the  following: 
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1.  Haze  1 1 i ne  CRT  Display 

2.  Hazel  tine  Keyboard 

3.  Hazeltine  Thermal  Printer 

4.  Hazeltine  Cassette  Tape  Unit 

5.2.5  Processor  User  Console  (AN/AYK-15A) 

The  processor  User  Console  enables  the  user  to  communicate  with 
the  AN/AVK-15A  processors.  The  User  Console  configuration  is  shown  in 
Figure  43.  The  User  Console  was  supplied  by  the  DAIS  processor  (AN/AYK-15A) 
vendors  to  support  the  debug  and  test  the  mission  software  under  non-real¬ 
time  conditions.  The  functions  the  user  is  able  to  perform  are: 

1.  Clear  Processor 

2.  Display/Modify  Memory 

3.  Display/Modify  CPU  General  Registers 

4.  Display/Modify  Instruction  Counter  (IC) 

5.  Display/Modify  Fault  (FT)  Register 

6.  Display/Modify  Status  Word  (SW)  Register 

/.  Display/Modify  Interrupt  Mask  (IM)  Register 

8.  Display/Modify  BCI  Control  Registers 

9.  Display/Modify  Timer  A 

10.  Display/Modify  Timer  B 

11.  Dump  Memory  Block 

12.  Step  Processor 

13.  Step  BCI 

14.  Set/Remove  Breakpoints 

15.  Execute  Processor 

16.  Load  from  Disk 

17.  Write  to  Disk 

18.  Control  Printer 

19.  Clear  User  Console 

20.  Read  User  Console  Status 

21.  Allow  Processor  Functions 

22.  Inhibit  Processor  Functions 

In  the  local  mode,  console  commands  are  issued  from  the  Hazeltine  keyboard. 
When  under  control  of  tne  DECsystem-10  or  PDP-11/40  via  the  PMIU,  the  User 
Console  is  in  the  remote  mode, 


5.2.6 


Performance  Monitor  Interface  Unit 


The  Performance  Monitor  Interface  Unit  operates  in  conjunction 
with  the  PMIU  software.  It  provides  the  STS  users  with  the  capability  to 
monitor  and  control  the  software  running  in  the  DAIS  processors  (AN/AYK-15A) . 
The  PMIU  software  sets  up  the  PMIU  for  real-time  operation  by  loading  the 
PMIU  control  registers  via  the  DEC  Unibus.  The  PMIU  then  performs  one  or 
more  of  the  following  CPU  monitor  functions: 


1.  Monitor  all  instruction  addresses 

2.  Monitor  a  specific  instruction  (OP-code) 

3.  Monitor  CPU  or  BCI  instructions  within  areas  of  memory 

4.  Monitor  memory  stores  within  specific  memory  locations 

5.  Monitor  operand  stores  where  operand  value  meets 
conditions  and  address  is  specified 
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FIGURE  43.  USER  CONSOLE  CONFIGURATION 


- 102- 


1 


6.  Monitor  memory  reads  within  specific  memory  locations 

7.  Monitor  all  out  of  sequence  branches 

8.  Monitor  all  interrupt  occurrences 

9.  Monitor  any  DMA  occurrence 

The  PM I U  also  performs  one  or  more  of  the  following  control  actions: 

1.  Halt  AN/AYK-15A  processors 

2.  Start  execution  AH/AYK-15A  processors 

3.  Single  Step  AN/AYK-15A  CPU  or  BCM  instructions 

4.  Clear  processor 

5.  Read  AN/AYK-15A  memory  or  registers 

6.  Write  AN/AYK-15A  memory  or  registers 

7.  Inhibit  and  enable  PDP-11  interrupts 

5.2.7  Simulated  Subsystem  Interface  Unit  (SSIU) 

The  Simulated  Subsystem  Interface  Unit  (SSIU)  provides  the  interface, 
control,  and  data  transfer  functions  required  to  interface  a  set  of  remote 
terminals  (RTs)  to  a  PDP-11  unibus.  Each  RT  interfaces  to  the  SSIU  via  a 
facility  Interface  Module  (FIM)  which  is  specially  designed  for  this  purpose, 
figure  44  is  an  interface  block  diagram  illustrating  the  SSIU  interconnection. 

The  SSIU  provides  the  interface  for  the  simulated  sensor  suite  that 
in  actual  operation  is  interfaced  by  up  to  sixteen  fully  populated  RTs  with 
iny  complement  of  Interface  Modules  (IMs).  A  FIM  occupies  a  single  RT  slot. 

It  responds  to  any  address  which  defines  an  IM  slot  and  IM  channel  for  which 
•he  data  were  actually  intended.  The  SSIU  uses  this  address  as  a  pointer  to 
:tore  and  retrieve  data  from  unibus  memory  in  preselected  locations  which 
ire  mapped  to  correspond  to  the  RT  configurations  begin  simulated. 

The  SSIU  uses  a  PDP  11  unibus  memory  that  can  support  a  Direct 
Memory  Access  (DMA)  data  rate  of  at  least  1  MHz  for  each  16-bit  word  and  can 
operate  in  a  burst  mode  (dedicated  unibus)  for  up  to  34  microseconds.  Other 
features  of  the  SSIU  include: 

1.  At  the  end  of  each  data  block  written  into  unibus 
memory,  transferring  a  pointer  by  DMA  to  a  pre¬ 
selected  location  defining  the  starting  address  of 
the  data  block 

2.  Providing  an  interrupt  at  the  end  of  preselected 
messages 

3.  Providing  an  interrupt  for  several  types  of  error 
condi tions 


Set  up  of  the  SSIU  memory  and  control  registers  and  monitor  and  control  of  the 
SSIU  during  operation  are  provided  via  unibus  Programmed  Input/Output  (PIO). 


5.2.8 


Super  Control  and  Display  Unit  (SCADU) 

The  Super  Control  and  Display  Unit  (SCADU)  operates  in  conjunction 
with  the  PMC  software.  It  provides  the  : TB  or  STS  users  with  the  capability 
to  monitor  and  control  the  software  running  in  the  DAIS  processor  (AN/AYK-15) . 
It  collects,  stores  and/or  breakpoints  on  the  data  received  from  the  DAIS 
processor  (Table  8)  and  then  halts  the  DAIS  processors  and/or  BCIUs  and 
interrupts  the  PMC  PDP-11/40. 

The  DAIS  processors  make  available  to  the  SCADU  information  accessed 
or  stored  in  the  processor's  memory.  Based  upon  the  processor's  memory  con¬ 
troller  micro-code  addresses,  the  SCADU  determines  which  data  (Table  8  )  is 
being  received  from  the  processor  over  the  parallel  multiplex  data  bus.  The 
SCADU  then  selectively  monitors  and  stores  this  data. 

The  PMC  software  sets  up  the  SCADU  for  real-time  operation  by 
loading  the  SCADU  control  RAMs  with  specific  micro-programmed  monitor  and 
control  actions.  The  SCADU  then  performs  one  or  more  of  the  following  monitor 
functions : 


1.  Monitor  all  instruction  addresses 

2.  Monitor  a  specific  instruction  (Op-code). 

3.  Monitor  all  jump  instructions  which  cause  a  branch. 

4.  Monitor  all  memory  stores. 

5.  Monitor  all  memory  accesses. 

6.  Monitor  all  interrupt  occurrences. 

7.  Monitor  all  DMA  occurrences. 

Tne  SCADU  also  performs  one  or  more  of  the  following  control 

actions : 

1.  Breakpoint  (halt)  upon  occurrence  of  one  of  the 
specific  functions  above. 

2.  Log  the  data  in  SCADU  buffer  (trace)  with  a  time 
tag. 

3.  Compare  the  function  with  user's  specific  value 
(fixes  point  or  floating  point  numbers)  and 
brec:  point. 

4.  Halt  processors  and  BCIUs. 

5.  Interrupt  PDP-11/40. 

6.  Start,  stop,  or  reset  the  time  tag  timer. 

After  the  appropriate  control  actions  have  occurred,  the  PMC  soft¬ 
ware  reads  the  data  collected  in  the  SCADU  buffer,  and  reinitiates  the  same 
or  a  new  operation. 
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TABLE  8.  DATA  AVAILABLE  TO  SCADU  FROM  AN/AYK 


0.2.9 


ITB  Powe^y  Dijytr  i  but  ion  _and  Control 

The  1TB  Power  Distribution  and  Control  System  (PDS)  simulates 
aircraft  electrical  system  power  for  the  DAIS  core  hardware.  The  PDS  simu¬ 
lates  three  power  sources:  battery,  master  AC  generator,  and  Ram-Air  Turbine 
(RAT).  The  output  of  the  simulated  power  sources  provides  power  to  two  sets 
(AC  and  DC)  of  three  electrical  bus  systems:  emergency,  primary,  and  second¬ 
ary.  Each  DAIS  core  hardware  element  is  capable  of  simulated  operation  on  any 
one  of  tiie  electrical  buses.  Also,  each  individual  hardware  element  has  an 
on/off  control.  This  permits  simulated  power  control  or  power  failure  of  any 
one  of  the  power  sources,  simulated  electrical  buses,  or  individual  equip¬ 
ments.  The  PDS  includes  provisions  for  software  control  of  the  power  sources, 
electrical  buse  ,  or  individual  equipments.  This  software  control  is 
accomplished  via  a  PDP-11/40. 

The  PDS  system  controls,  distributes,  and  filters  the  power  to  each 
of  the  DAIS  core  hardware  elements.  The  PDS  system  also  controls  and  dis- 
tribures  power  to  the  support  hardware. 

..2.10  ITB  Tesc  Control  Center 

The  lib  lest  Control  Center  (TCC),  shown  in  Figure  40,  provides  a 
entralized  point  for  control  of  the  entire  ITB.  The  TCC  contains  the  terminals 
wnich  can  control  the  PMC  and  SSDF  PDP  11  processors  and  the  DECsystem-10 
simulation  models  via  the  PMC.  Both  system  checkout  and  operation  can  be  con- 
srolled  from  the  TCC.  The  DAIS  displays  and  the  out-the-window  scene  are  also 
lisplayed  on  CRT  monitors  at  the  TCC. 

.1.2.11  Controls  and  Backup  Instruments  System  ( LB  IS) 

The  CBIS  consists  of  the  DAIS  cockpit  flight  controls  and  displays 
that  are  not  part  of  DAIS.  The  controls  include  the  throttle,  stick,  rudder 
control  and  discretes.  The  displays  are  the  basic  flight  instruments  including 
the  standby  ADI,  altimeter  and  warning  lights.  The  CBIS  interfaces  to  the  ITB 
by  means  of  the  backup  C/S  interface  unit  which  provides  digital  to  analog 
conversions  and  a  digital  link  to  the  SSDF  (URT)  PDP-11/40. 

5.2.12  ITB  Equipment  Racks 

The  ITB  equipment  racks,  as  shown  in  Figure  42,  include  the  ITB 
hardware  as  specified  above  as  well  as  power  supplies;  special  interface 
panels  (multiplex  data  bus  patch  panel,  Processor/BCM  breakout  test  patch 
panel,  and  CIU/R5-232  patch  panel);  power  control  panels  and  processor  control 
pa  ne  1 . 


- 107- 


d.3  ITB  _Support_  Software^  and  PUP-11  Piuu'y^ii-j 

Support,  software  is  resident  in  the  PU*  - 1 1  m  .ces  ,-.<r 
5.3.1  Performance  Monitor  and  Control 


The  Performance  Monitor  and  Control  (PMC)  software  resides  in  a 
G144  System  (PDP-11/40)  under  RT  11.  It  is  useu  to  set  up,  control,  cno 
monitor  the  Mission  Software  resident  in  the  DAIS  p"C';essors  (AU/AYt  - ISA) . 

The  PMC  is  capable  of  servicing  from  one  to  four  DAIS  processors  at  one  time 
It  simultaneously  monitors  the  multiple:-  bus  traf f i-  via  the  BMC  and  rtcor  • 
selected  DAIS  system  data  for  post-test  analysis. 

Trie  PMC  controls  the  SCADU's,  CIU's,  and  BMU.  T he  DAIS  Processor., 
are  moni cored  and  controlled  through  the  SCADU's  and  the  CIU's.  The  PMC 
starts  and  stops  the  set  of  DAIS  Processors.  he  DAIS  processor  Mission 
Software  is  loaded  from  or  dumped  to  the  DLCsystem-lU  host  simulation  pro¬ 
cessor  or  the  PDP  11  processors  under  nMC  control. 

The  PMC  sets  up  test  cases  which  define  the  procedures  and  data 
collection  for  a  simulation  run.  An  operator  is  able  to  set  up  the  test  b, 
means  of  an  interactive  interface  and  the  creation  of  a  test  control  file. 
The  test  control  file  is  correlated  with  the  DECsyslem-10  :. iirulation  so  tnat 
tne  collection  of  test  data  will  proceed  as  defined  by  the  file  as  the  simu¬ 
lation  progresses. 

The  PMC  supports  the  system  users  in  the  debugging  and  evaluation 
of  mission  software.  It  allows  selective  real-time  and  non- real- time  ga  of « 
ing  of  data  from  the  DAIS  processor  and  the  multiplex  data  bus.  The  PMC 
provides  a  repertoire  of  commands  to  perform  the  non-real -time  and  real-time 
functions  as  fol lows : 

1.  Manipulate  files  on  the  DECsysterr.-lO  and  PDP-11 
such  as  rename,  delete,  uopy,  oti.. 

2.  Load  or  dump  DAIS  processor  n.i  esirn  software  from 
or  to  the  PDP-11. 

3.  Perform  the  CIU  functions  as  defined  in  paragiapli 
5.2.3  when  the  DAIS  processors  are  halted. 

4.  Start  and  stop  (halt)  the  DAIS  processors  and  BClUs. 

5.  Set  up  the  SCADli  to  perform  specified  functions  as 
defined  in  paragraph  5.2. E;  during  real-time  operation. 

6.  Set  up  the  bus  monitor  to  record  or  breakpoint,  as 
defined  in  paragraph  5.2.2,  on  specific  multiplex  data 
bus  messages. 

7.  Display,  print,  or  log  the  data  collected  from  the  bus 
monitor  or  DAJS  processors  via  the  CIU  and  SCADU.  Data 
logged  on  a  disk  can  he  analyzed  later  by  a  Post  Run 

Ed i tor. 


8.  Provide  the  capability  to  examine  or  modify  DAIS 
processor  registers  ana  memory  locations  either 
with  absolute  or  symbolic  addresses. 

9.  Provide  interactive  capability  with  the  DECsystem- 10 
to  set  up  and  run  the  simulation  models. 

The  PMC  provides  the  capability  to  restart  Mission  Software,  along 
with  the  simulation  models,  from  a  system  snapshot  point.  This  is  accom¬ 
plished  by  dumping  Mission  Software  parameters  at  a  specified  PMC  breakpoint, 
and  reloading  these  parameters  to  restart  the  system.  This  snapshot  and 
restart  capability  is  used  for  repeated  testing  or  demonstrations  from  a 
specific  point  in  the  mission  profile. 

b.3.2  Performance  Monitor  Interface  Unit 


The  PMIU  software  provides  the  STS  users  with  the  capability  to 
'unitor  and  control  the  software  running  in  the  DAIS  processors (AN/AYK- 15A ) . 
'no  Performance  Monitor  Interface  Unit  (PMIU)  is  capable  of  controlling  up 
to  four  PMIUs  on  one  UNIBUS.  The  PMIU  software  is  designed  to  run  under  the 
•tT-11  operating  system  on  the  PDP-11.  The  PMIU  software  monitors  and  controls 
he  DAIS  processors  (AN/AYK- 15A)  and  monitors  the  multiplex  bus  traffic 
Through  the  PMIU. 

Tne  PMIU  software  sets  up  test  cases  which  define  the  procedures 
.nd  data  collection  for  a  simulation  run.  An  operator  is  able  to  set  up  the 
fest  by  means  of  an  interactive  interface  and  the  creation  of  a  test  control 
rile.  The  test  control  file  is  correlated  with  the  DECsystem-10  simulation 
o  that  the  collection  of  test  data  will  proceed  as  defined  by  the  file  as 
the  simulation  progresses. 

The  PMIU  software  supports  the  system  users  in  the  debugging  and 
evaluation  of  mission  software  by  allowing  selective  real-time  and  non-real¬ 
time  gathering  of  data  from  the  DAIS  processor  and  the  multiplex  data  bus. 

The  PMIU  provides  a  repertoire  of  commands  to  perform  the  non-real -time  and 
real-time  functions  as  follows: 

1.  Load  or  dump  DAIS  processor  mission  software  from  or 
to  tile  PDP-11. 

2.  Set  up  the  PMIU  to  perform  specified  functions  as 
defined  in  paragraph  5.2.6  during  real-time  operation. 

3.  Display,  print  or  log  the  data  collected  from  the 
multiplex  bus  system  or  DAIS  processors  using  the 
PMIU  Post  Run  Editor. 

o .  3 . 3  S ijnul ated  Subsystem  Data  Formatter  (SSDF/URT)  Software 

The  main  purpose  of  the  SSDF/URT  is  to  buffer  data  to  and  from  the 
DAIS  Models  Simulation  System  (DMSS)  and  to  provide  timing  signals  to  the 
DMSS.  The  SSDF/URT  software  sets  up  and  controls  the  URT,  double  buffers  the 
data  in  the  four-port  buffer  memory,  and  provides  a  user-selectable  display 
of  the  multiplex  data  bus  messages.  The  software  is  designed  to  run  on  both 
the  ITB  and  STS. 
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All  URT  data  areas  for  transni ss ion  and  reception  ot  data  are 
double  buffered  in  the  four  port  buffer  memory  (buffers  A  and  [■:  .  V.'h- 

models1  output  data  is  read,  the  SSDF/URT  waits  until  tie  nr  t  mmur 
and  switches  the  UR1  buffers.  lire  DMSS  output  for  Cfl'.  is  a  i  so  read  and 

processed  if  CBIS  is  on-line.  The  data  received  by  the  URT  for  trie  DMSS  is 
passed  to  the  DMSS  as  it  is  received.  The  UTIS/TCC  inputs  are  passed  to  * f 
DMSS  3 2  times  per  second. 

The  SSDF/URT  and  the  DMSS  use  a  handshaking  flag  to  prevent  the 
reading  and  writing  of  partially  updated  messages  in  the  DMA  window. 
Initially,  the  SSDF/URT  sets  the  flag  to  a  one.  When  the  clock  interrupt  is 
generated  to  start  a  new  DMSS  cycle,  tne  SbUF/LRT  completes  writing  any 
partial  messages  to  the  DMA  window  ana  then  interrupts  the  DFCsyst.em-1  .  In 
DMSS  sets  the  flag  to  a  two,  reads  all  inputs  and  tnen  sets  the  flag  to  a 
three.  While  the  DMSS  is  reading  its  inputs,  the  SSDF/URT  reads  the  DMSS 
output  and  waits  for  the  flag  to  be  set  to  three.  At  this  time,  the  SSUF/LF 
sets  the  flag  back  to  one. 

The  minor  cycle  number  (received  with  tne  synchronize  mode  command 
is  maintained  by  the  SSDF/URT  along  with  the  major  cycle  number  (number  of 
times  the  minor  cycle  count  transitions  from  127  tc  zero).  Tnese  two  values 
are  written  into  the  DMA  window  as  they  change  to  allow  tagging  of  any 
recorded  data. 

In  non-real -time  mode,  the  SSDF/URT  performs  the  following: 

1.  Manages  memory  initialization. 

2.  Utilizes  user-defined  tables  to  initialize  t fie  URT 
RAMS  and  registers  for  the  specific  mission. 

3.  Initializes  the  four-port  buffer  memory,  display 
processor,  CBIS  and  keyboard. 

4.  Accepts  user  configuration  conmands  to  specify  the 
fol lowing: 

a.  Whether  or  not  the  SSDF/URT  software  should  keep 
cycling  the  real-time  models  when  mission  software 
stops. 

b.  Whether  or  not  the  URT  should  be  set  up  to  respond 
to  minor  cycle  messages  to  buc  audress  one  required 
for  one-processor  configuration  to  respond  to  a 
dummy  minor  cycle  message). 

5.  Simulates  a  mass  memory  device  using  the  PDP-11  disk 
unit  to  allow  loading  of  STS  and  ITB  processors  over 
the  DAIS  multiplex  data  bus. 

6.  Initializes  a  real-time  clock  to  provide  interrupts 
32  times  per  second  to  drive  the  real-time  models. 
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Tne  first  minor  eye  I e  message*  received  or  a  user  command  causes 
the  bSDF / UKT  to  enter  real-time  mode.  In  real-time  mode,  the  SSDf/URT 
performs  the  following  functions: 

1.  Maintains  and  displays  minor  and  major  cycle  counts 
and  passes  them  to  the  PMC  software  if  required. 

2.  Generates  interrupts  to  the  DECsystem-10  to  cycle  the 
real-time  models  based  on  timer  interrupts. 

3.  Moves  data  received  from  the  URT  and  SSIU  to  the  DMA 
window. 

4.  Controls  the  swapping  of  the  URT  double  buffers. 

b.  Reads  the  models  output  data  from  the  DMA  to  the 
four-port. 

b.  Uses  the  tinier  and  DECsystem-10  interrupts  to  control 
access  to  the  DMA  window. 

7.  Inputs  and  outputs  CBIS  data  (performing  all  necessary 
formatt ing, . 

8.  Hanoi es  mode  command  interrupts  from  the  URT  as 
required  to  make  the  URT  respond  like  a  real  RT. 

9.  Maintains  displays  of  all  pertinent  information. 

; ,3.4  Evans  and  Sutherland  Graphics  System 

The  Evans  and  Sutherland  graphics  system  is  used  to  generate  a 
,:ockpit  out-the-window  scene.  The  out-the-window  scene  is  controlled  by  the 
simulation  software  so  that  the  scene  viewed  from  the  cockpit  has  the  correct 
dynamic  orientation  to  synchronize  with  the  simulated  aircraft  motion.  The 
graphics  interface  software  transforms  aircraft  attitude  and  position  data 
obtained  via  the  DECsystem-10  DMA  window  from  the  simulation  software  program 
into  a  form  that  can  drive  the  Evans  and  Sutherland  graphics  system. 

b . 3 . 5  ITB  PDP-11  Processors 

The  PDP-11  processors  include: 

1.  Each  PMC  ( PM I U )  and  SSDF  (URT)  processor  has  a  complex 
consisting  of  one  DEC  GT-44  PDP-11/40  processor,  and 
other  peripherals. 

2.  The  Evans  and  Sutherland  Graphics  interface  processor 
consists  of  a  PDP-11  processor. 

b .  4  STS  Support  Hardware 

The  initial  STS  hardware  subsystems  were  identical  to  that 
described  for  the  ITB: 
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1. 

One 

Universal  Remote  Terminal 

2. 

One 

Bus  Monitor  Unit 

3. 

Two 

Super  Control  and  Display  Units 

4. 

Two 

Console  Intelligence  Units 

5. 

Two 

Hazeltine  Terminals 

6. 

One 

Four-Port  Buffer  Memory 

7. 

One 

HAS  SCADU 

The  current  STS  hardware  subsystems  are  identical  to  that  describee! 
for  the  ITB  or  are  described  previously: 

1.  One  Universal  Remote  Terminal 

2.  One  Bus  Monitor  Unit 

3.  Two  Performance  Monitor  Interface  Units 

4.  Two  User  Consoles 

5.  One  Four-Port  Buffer  Memory 

The  STS  Power  Distribution  and  Control  (PDS)  system  controls, 
distributes  and  filters  the  power  to  each  of  these  DAIS  core  elements  ana 
the  STS  support  hardware. 

The  STS  Test  Control  Center  (the  initial  STS  TCC  is  shown  in 
Figure  36  and  the  current  STS  TCC  is  shown  in  Figure  37)  provides  a  cen¬ 
tralized  point  for  control  of  the  entire  STS.  The  TCC  contains  the  terminals 
which  can  control  the  PMC  and  SSDF  PDP-11  processors  and  the  DECsystem-10. 

5 • 5  STS  Support  Software  and  PDP  11  JProce ssor 

The  PMC  software  for  STS  is  identical  to  the  ITB  PMC  support  soft¬ 
ware  as  described  in  paragraph  5.3.1. 

The  PMIU  software  for  the  STS  is  identical  to  the  ITB  PMIU  support 
software  as  described  in  paragraph  5.3.2. 

The  SSDF  (URT)  software  for  STS  is  identical  to  the  ITB  SSDF  (URT) 
software  except  interfaces  for  the  SSIU  and  CBIS  arp  not  operated. 

The  PMC  PDP  GT-44  System  and  SSDF  (URT)  PDP  GT-44  System  are  simila 
to  the  ITB  PDP-11  processor. 

5 . 6  DECsystem-10  Host  Simulation  Process or 

The  DECsystem-10  facility  block  diagram  is  shown  in  Figure  45. 

The  KI  DECsystem-10  CPU  is  used  with  the  interfaces  and  peripherals  shown 
in  the  block  diagram.  The  DECsystem-10  facility  is  a  conventional  DEC 
configuration  except  for  the  Direct  Memory  Interface  Controller  which 
provides  a  DMA  window  access  to  the  DECsystem- 10  memory  for  data  transfer 
between  the  DEC-system-10  and  the  PDP-11  processors. 
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FIGURE  45.  DECsystem- 10  HOST  SIMULATION  PROCESSOR  CONFIGURATION 


5.7 


Simulation  Software 


The  Simulation  Software,  a  lso  known  as  the  DAIS  Models  c  i-  i.  1  a  f  o  n 
System  (DMSS)  is  resident  in  the  DECsys tern- 10  host  simulation  proces.oi  . 

The  DMSS  consists  of  seven  functional  types  of  software: 

a.  Executive  software  responsible  for  overall  simulation 
control ; 

b.  Sensor  models,  which  simulate  the  on-board  aircraft 
sensors ; 

c.  SLU/STORES  models,  which  simulate  functional  responses 
of  weapon  systems  to  the  operational  Stores  Management 
softwa re; 

d.  Aircraft/Environment  models,  which  provide  airframe 
dynamics,  flight  control  dynamics,  and  propulsion 
data  in  response  to  pilot  and  external  system  actions; 

e.  Interface  utilities,  which  provide  access  to  the  Crew 
Station  cockpit  controls  and  displays  and  to  the  Evans 
and  Sutherland  Picture  System; 

f.  Checkpoint/Reset  utilities,  which  allow  for  the  capa¬ 
bility  to  reset  the  scenario  in  both  run  mode  and 
non-run  mode  system  operation;  and 

g.  Scenario  Generator  software,  which  can  be  used  in 
place  of  the  Aircraft/Environment  software,  and  will 
simulate  all  inputs  and  outputs  required  to  "fly" 

a  predefined  flight  scenario. 

The  simulation  software  system  as  a  whole  operates  with  a  major  cycle 
(computational  cycle)  rate  of  32  times  per  second.  It  should  be  noted,  however, 
that  not  all  models  operate  at  this  maximum  rate.  The  models  are  broken  into 
specific  rate  group  subsets,  based  uoon  computational  reuui cements  (speed  arc1 
accuracy)  and  operate  at  various  speeds.  Data  is  transferred  32  times  pet- 
second,  based  on  the  highest  rate  group  requirements.  The  data  transfer  infor¬ 
mation  required  by  the  simulation  system  from  Mission  Software  is  initiated 
when  the  SSDF/URT  PDP-11  processor  generates  an  interrupt  to  the  DECsys tem-10 
at  the  start  of  each  computational  cycle.  The  simulation  system  then  reads  all 
inputs  from  the  PDP-11  and  then  generates  an  interrupt  back  to  the  PDP-11.  The 
simulation  then  performs  its  calculation  and  outputs  its  data  to  be  provided  tc 
Mission  Software  to  the  DMA  window.  The  SSDF/URT  PDP-11  then  accepts  the  data 
and  transfers  it  to  Mission  Software. 


The  picture  system  shown  in  Figure  46  consists  of  a  simulation 
software-control  led  ground  display  graphics  generator  and  projector  syscem. 
The  graphics-generated  display  of  the  ground  as  seen  by  the  pilot  in  the 
simulated  cockpit,  is  projected  on  a  motion  picture  screen  in  front  of  the 
cockpit. 


An  Evans  and  Sutherland  graphics  system  generates  an  idealized 
pattern  which  represents  ground  terrain,  targets,  runway,  etc.  The  Evans 
and  Sutherland  is  controlled  by  the  DECsystem-10  simulation  software  via 
the  PDP  11  processor.  The  graphics  are  generated  on  a  stroke  CRT  display 
and  monitored  by  a  closed  circuit  television  camera.  The  TV  image  is  trans¬ 
mitted  to  the  Advent  projection  subsystem. 


Data  Reduction  and  Analysis  Software 


The  Data  Reduction  and  Analysis  Software  (DRAS)  processes,  formats, 
>nd  outputs  data  from  the  Integrated  Test  Bed  (ITB)  or  the  Software  Test 
tand  (STS).  The  DRAS  is  composed  of  two  computer  programs  which  perform  the 
allowing  functions: 


•  Read  ITB/STS  data  from  tape  or  disk 

•  Convert  data  from  binary  to  decimal 

•  Rewrite  selected  data  onto  a  disk 

•  Read  the  data  from  the  disk  file 

•  Generate  report  files 

•  Generate  a  disk  file  suitable  for  plotting 


The  report  files  generated  by  the  DRAS  include  a  data  report,  an 
-vent  and  time  report,  and  an  error  message  report.  The  data  report  contains 
a  time  history  of  selected  parameters  recorded  during  ITB/STS  system  operation. 
The  event  and  time  report  contains  a  block  of  STS/ITB  data  recorded  at  the 
time  a  discrete  event  changes.  These  events  include  changes  in  navigation, 
steering,  or  master  modes,  weapon  release,  thrust,  INS  alignment  status,  and 
weight-off-gear.  The  error  message  report  contains  a  list  of  all  errors 
which  may  have  occurred  during  processing. 


DRAS  is  used  to  support  system  testing  and  DMSS  testing.  It  is 
also  used  to  provide  a  permanent  record  documenting  the  successful  completion 
of  formal  demonstrations. 
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FUNCTIONAL  CONFIGURATION  -  PICTURE 


°.  0  SOFTWARL  CONVERSION 

o.l  Mission  Software  Conversion 

The  Mission  Software  was  converted  from  JOVIAL  J73/I  to  JOVIAL  J73. 
The  conversion  and  retest  effort  took  almost  15  months  because  corrections  and 
nanges  were  being  made  to  the  new  JOVIAL  J73  compiler  simultaneously.  The 

M5U  conversion  was  accomplished  in  an  orderly  and  organized  manner. 

o.l.l  Executive  Conversions 

The  executive  software  underwent  three  stages  of  conversions. 

'  irst,  the  executive  was  converted  from  MIL-STD- 1553A  to  MIL-STD-1553B  bus 
rotocol.  The  second  stage  of  conversion  was  the  retargeting  of  the  executive 
rrom  the  AN/AYK-15  processor  to  the  M I L- STD- 1750  (AN/AYK-15A) .  The  last  stage 

■  r  conversion  was  the  translation  of  the  source  code  from  J73/I  to  MIL-STD- 
.'tS9B  (JOVIAL  J73).  At  the  completion  of  each  of  the  three  conversions,  the 

■  -ecutive  was  fully  tested. 

The  conversion  to  MIL-STD-1553B  bus  protocol  resulted  in  simpli- 
cation  of  the  bus  control  functions  of  the  executive.  A  small  amount  of 
•design  of  the  executive  was  required  to  incorporate  the  new  bus  protocol 
f iciently. 

The  conversion  to  AN/AYK-15A  required  modifications  primarily  to 
' ne  assembly  language  routines  of  the  executive.  These  routines  contain  the 
•  ichine-dependent  interface  such  as  interrupt  handlers  and  Bus  Control  Inter- 
aces.  The  new  processor  also  had  a  different  repertoire  of  machine  instruc- 
ions  which  also  affected  these  routines.  Also,  the  use  of  the  JOVIAL 
/  M/AYK-15A  code  generator  necessitated  the  inclusion  of  a  stack  management 
■/stem  into  the  executive. 

The  language  conversion  to  JOVIAL  involved  primarily  syntax  changes. 
However,  several  semantic  changes  were  required  because  of  strong  type  check¬ 
ing  and  addition/deletions  of  data  types. 

6.1.2  Application  Software  Conversion 

The  application  software  was  converted  to  JOVIAL  J73  and  retested, 
f-  irst,  the  Compool  Blocks  ana  the  Comsubs  were  converted  because  these  are 
used  by  the  other  tasks.  Then,  the  application  tasks  were  converted.  The 
acceptance  test  programs  (ATP’s)  were  converted  along  with  each  task  so  that 
testing  coul-.  be  kept  up-to-date. 

Some  of  the  changes  required  to  convert  the  tasks  were  trivial; 
square  brackets  were  changed  to  parentheses  and  the  syntax  of  certain  JOVIAL 
statements  was  modified.  Many  of  the  data  items  had  to  be  converted  so  that 
the  data  types  matched.  The  structure  of  the  data  tables  in  the  common  data 
area  had  to  be  redefined. 

6.2  Core  Element  Test  Software  Conversion 

The  Controls  and  Displays  (C&D)  Acceptance  Test  Program  (ATP)  was 
converted  from  JOVIAL  J73/I  to  JOVIAL  J73.  The  ATP  handles  the  interface 
between  the  C&O  devices  and  the  test  software;  it  also  controls  testing  by 


prompting  the  user,  and  it  oer forms  the  actual  acceptance  test.  I  he  only 
problems  encountered  during  the  conversion  involved  «-edef  ininn  cpo;  if  lea 
data  tables;  other  required  changes  were  simple  to  make. 

The  Remote  Terminal  ( RT )/ Interface  Module  (IM)  Diagnostics  exer¬ 
cises  RT  and  IM  hardware  through  a  senes  of  tests  and  a  1 1  ows  the  isolation 
of  errors.  The  RT/ I M  Diagnostics  has  two  versions: 

1.  The  original  is  loaded  in  an  AN/AYK-15  processor 
and  uses  the  MIL-SI D- 1553A  multiplex  bus  system 
for  testing. 

2.  The  second  is  loaded  in  an  AN/AYK-15  processor,  as 
the  original,  and  uses  the  MIL-STD- 1553B  multiplex 
bus  system  for  testing.  This  version  was  created 
by  converting  the  original  diaono'-tics  to  meet  MIL- 
STD- 1553B. 


The  RT/IM  Diagnostics  tests  are  described  in  tne  hardware  integration  and 
test  section. 

6.3  Multiplex  Diagnostics  Software  Con vers  ion 

The  Master  Multiplex  System  Diagnostics  are  a  set  of  up  to  32  tes 
that  test  the  multiplex  bus  system  and  its  devices.  These  devices  include: 

1.  Master  processor  and  BCIU  or  Master  processor/BCM 

2.  Remote  processor  and  BCIU  or  Remote  processor/BCM 

3.  Remote  Terminal 

4.  Universal  Remote  Terminal 

5.  System  Mass  Memory 

There  are  three  versions  of  the  Multiplex  Diagnostics: 

1.  The  original  is  loaded  in  an  AN/AYK-15  processor 
and  uses  the  MIL-STD- 155 3 A  multiplex  bus  system 
for  testing. 

2.  The  second  version  is  loaded  in  an  AN/Avk-15  pro¬ 
cessor,  as  the  original,  and  uses  the  MIL-STD- i 553B 
multiplex  bus  system.  This  version  was  created  by 
converting  the  original  diagnostics  to  meet  MIL-STD- 
1553B  and  adding  new  tests. 

3.  The  last  version  is  loaded  in  an  AN/AYK-15A  processor 
and  uses  the  MIL-S1D-I553B  multiplex  bus  system.  The 
version  was  created  by  converting  the  second  diagnostics 
to  AN/AYK-15A  instruction  set. 

Table  9  contains  a  list  of  the  tests  for  all  the  versions.  A  list  of 
devices  used  in  the  test  by  each  version  is  found  in  Tables  10  through  12. 

The  Command  Generation  software  (CMDGEN)  is  a  general  purpose 
program  designed  to  give  a  user  the  following  capabilities: 


TABLE  9.  LIST  OF  ALl  me  .-Ioa  ulhuUUijfiLj  TlST 


TABLE  9  .  LIST  OF  ALL  MUX  DIAGNOSTICS  TESTS  (CON 1 T) 
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TABLE  12.  DEVICES  U^ED  BY  EACH  TEST  IN  MUX  DIAGNOSTICS  AN/AYK-15A,  1 55 JB 


TABLE  12.  DEVICES  USED  BY  EACH  TEST  IN  MUX  DIAGNOSTICS  AN/AYK-15A,  1553B  (Con't) 


1.  Build  and  execute  up  to  .  uU  bus  ;n%t  •  uct '.hi.  . 

These  instruct  ions  :dusi*  cornu nd-j  .mu,  r  !<• t  ••  • 
be  sent  on  tlm  multiple.*.  Pus  by  t»-e 

2.  specify  the  data  to  be  sent  on  the  multiplex  bus 
by  the  BCM. 

3.  Load  BCM  registers. 

'i .  Specify  the  bus  address  used  by  the  BCM  control  led 
oy  (IMOGEN. 

5.  Cause  the  BCM  to  run  in  either  master  or  remote  mode . 

There  are  three  versions  of  CMDGEN: 

1.  AN/AYK-15,  MIL -STD-1553A 

2.  AN/AYK-15,  MIL-STD- 1 553B 

3.  AN/AYK- 15A,  MIL-STD- 1553B 

The  development  of  these  versions  was  similar  to  the  dcvel oproent  of  the  Mas:*' 
Multiplex  Diagnostics. 

6.4  175 QA  ATP 

The  AN/AYK-15A  Acceptance  Test  Program  (ATP',  was  converted  to  test 
the  MIL-STD-1750A.  The  ATP  consists  of  extensive  tests  for  each  instruction 
hi  the  instruction  set.  The  first  step  in  converting  .the  ATP  was  to  define  tn» 
differences  in  the  two  instruction  sets  (MI L- STD- 1 7 50  and  MIL-STLM750A).  Any 
differences  in  the  instruction  sets  resulted  in  differences  in  the  two  ATP's. 

Ui fferences  include: 

•  Several  instruction  set  changes  were  made  (PER  and  CrR 
were  combined  to  make  RCfP..  for  example). 

•  New  interrupts  were  defined. 

•  New  options  were  defined  (su^.h  as  expanded  memory). 

•  Stack  was  made  to  increment  in  opposite  direction. 

The  general  instruction  modules  required  minor  changes  because  of 
instruction  set  differences.  The  executive  module  needed  to  be  modified  to 
include  new  interrupt  handlers,  stack  differences,  and  some  'xparrjed  memory 
processing. 

Several  new  tests  were  written  to  test  the  expanded  memory  option 
and  the  various  options  associated  with  expanded  memory,  such  as  access  lock/ 
key,  E/W,  bit,  and  page  register  operations.  These  modules  were  written  as 
stand-alone  tests.  New  tests  were  also  written  to  test  new  instructions  such 
as  BEX  (branch  to  executive)  and  V 1 0  (vectored  I/O).  These  were  designed  to 
be  run  with  the  executive  module. 
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7.0 


HARDWARE  CONVERSION 


The  hardware  conversion  of  the  DAIS  ITB  consisted  of  upgrading  the 
BCIU's  and  RT's  to  be  15536-compatible  and  subsequently  replacing  the  BCIU's 
and  associated  AN/AYK-15  processors  with  the  integrated  AN/AYK-15A  processor/ 
h.'.M.  The  integration  and  test  of  the  AN/AYK-15A  is  described  elsewhere  in  this 
eport.  This  section  will  concentrate  on  the  multiplex  conversion. 

,  .  1  Multiplex  System  Conversion 

Shortly  after  MIL -STD- 1 553B  was  formally  approved  and  published,  the 
r'AlS  Problem  Report  Board  (PRB)  appointed  a  working  group  composed  of  AFWAL  and 
■  contractor  personnel  to  perform  an  impact  assessment  of  converting  DAIS  to  the 
ew  standard.  The  working  group  identified  issues,  developed  technical  approaches 
-.n  resolving  them,  and  drafted  costs  and  schedule  plans  for  accomplishing  the 
■reversion.  Based  on  this  plan  DAIS  management  elected  to  perform  an  in-house 
•  '.version  of  the  BCIU's  and  let  a  sole  source  contract  for  the  upgrade  of  the  RTs. 

The  impact,  assessment  report  identified  twelve  technical  tasks  as 

‘i.  'lows: 


•  Delete  Message  Error,  Busy,  and  Terminal  Fail  Bit 
suppression  for  Transmit  BIT  and  Transmit  Last 
Command. 

•  Update  Last  Command  Register  for  Transmit  Status 
and  Transmit  BIT  (previously  not  updated). 

•  Design/implement  new  system  control  procedure  for 
RT  Asynchronous  protocol  which  does  not  require 
the  reset  mode  command. 

•  Design/implement  new  system  control  procedure  for 
interprocessor  asynchronous  protocol  which  does  not 
use  status  embedded  ARV  or  require  reset  status  code. 

•  Define/implement  a  Reset  Built-In-Test  (BIT)  without 
a  Reset  BIT  Mode  Command. 

•  Define/implement  a  new  bus  shutdown  procedure  using 
1553B  Mode  Commands. 

•  Implement  RT/Subsystem  Retry  at  the  RT/IM  Level. 

•  Change/delete  mode  command  assignments  for  DAIS/ 

1553B  equivalent  command. 

•  Do  not  suppress  the  busy  state  in  the  status  response 
for  transmit  status. 

•  Assign  a  new  asynchronous  .ubaddress. 
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•  Include  subaddress  31  as  an  additional  mode  commas 
indicator  in  both  faster  and  Remote  BCIU. 

•  Re-assign  all  status  bit  discretes. 

These  tasks  reflect  the  fact  that  whereas  1553A  had  left  mode  code 
definitions  optional,  1553B  spelled  them  out  in  detail  and  did  not  include 
all  the  mode  codes  DAIS  had  defined.  The  more  significant  differences  were 
in  the  areas  of  asynchronous  operations,  RT/IM  error  handling  and  the  use  or 
subaddress  31  for  mode  codes. 

The  asynchronous  differences  resulted  from  the  fact  that  DAIS  had 
embedded  an  Asynchronous  Request  Vector  (ARV)  in  the  status  word  and  used  a 
mode  code  to  clear  the  ARV  after  it  had  been  read.  M I L -STD- 1 553B  allowed  only 
the  service  request  bit  in  the  status  word,  moved  the  ARV  to  the  vector  word 
and  provided  a  mode  code  to  read  the  vector  but  none  to  clear  it. 

For  the  RT/IM  error  handling  DAIS  had  defined  a  status  word  bit  and 
a  mode  code,  Interrogate  Module  Error  Register,  to  identify  the  IM  and  channel 
in  error.  MIL-STD- 1553B  included  neither  the  status  word  bit  nor  the  mode  codt  . 

Subaddress  31  had  been  used  in  DAIS  to  interrupt  a  remote  processor 
(the  only  subaddress  on  which  a  message  would  cause  an  interrupt)  ?■  s  part  of 
the  asynchronous  protocol.  The  use  of  this  for  a  mode  code  required  DAIS  to  use 
another  subaddress  for-  asynchronous  messages  in  addition  to  the  modification*: 
necessary  to  recognize  31  as  signaling  a  mode  code. 

It  is  interesting  that  recognizing  subaddress  31  for  mode  cod  js  is 
the  only  modification  of  the  BCIU  actually  requiring  a  hardware  change.  All 
other  modifications  were  accomplished  in  BCIU  microcode.  The  RT  modification1, 
included  an  automatic  retry  of  the  IM/chc.nnel  in  error  and  this  was  part  of 
the  motivation  for  not  attempting  the  RT  upgrade  in  house. 

The  conversion  of  DAIS  to  1553B  was  accomplished  ir  a  three-pd,  *> 
effort  of  system  engineering,  documentation,  ana  dove-'1  ourent .  More  than  ■  a  1 + 
the  total  effort  was  devoted  to  documentation,  resulting  ;o  a  complete  -e*  o* 
cure  element  specifications  fully  1553B-compatible.  The  final  testing  win. 
accomplished  in  two  steps,  the  first  using  a  PRPV  simulator  (RAM)  to  debug  tte 
microcode  changes.  The  second  step  involved  burning  the  real  PROMS.  This 
testing  was  completely  successful  and  accomplished  ahead  of  schedule.  An 
additional  two  units  were  converted  and  provided  to  the  developers  of  the  AN/ 
AYK-15A  to  aid  in  their  testing. 
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8.0 


INTEGRATION  AND  TEST 


The  modular  structure  and  well-defined  interfaces  of  botn  the  hard¬ 
ware  and  software  elements  in  the  DAIS  System  Architecture  greatly  facilitate 
the  integration  and  test.  A  step-by-step  approach  was  taken  to  test  and  inte¬ 
grate  both  the  DAIS  core  elements  and  the  support  hardware  and  software. 
Initially,  stand-alcng  tests  were  performed  on  individual  elements.  Then, 
these  elements  were  incrementally  integrated  and  tested  until  the  system  was 
completed.  The  following  sections  highlight  several  of  the  key  techniques 
which  contributed  to  the  successful  and  rap’d  integration  and  test  activities. 

3. 1  stand-alone  Tests 

8.1.1  Core  Element  Hardware 

As  each  core  element  subsystem  was  received  from  the  contractor, 
stand-along  acceptance  tests  were  performed.  First,  the  contractor  supplied 
‘est  support  equipment  and  software.  These  tests  were  then  augmented  with 
Fw'AL  and  SITC  tests.  The  tests  were  developed  to  verify  all  the  electrical 
.nd  functional  interfaces  of  each  subsystem.  In  several  cases,  the  contractor- 
applied  tests  were  not  very  comprehensive,  and  the  test  support  equipment  did 
ot  allow  complete  dynamic  testing  of  all  the  functional  interfaces.  As  a 
esult,  specifically  for  the  multiplex  equipment,  complete  acceptance  testing 
A  these  core  elements  was  not  completed  until  the  subsystem  was  integrated 
’nd  tested  with  other  system  elements  as  discussed  in  the  hardware  integration 
^nd  test  section  below. 

The  AN/AYK-15A  processor  has  an  Acceptance  Test  Program  that  runs 
.he  AN/AYK-15A  in  a  stand-alone  state.  The  ATP  is  an  integral  part  of  the 
vAIS  processor  qualification  testing  package.  The  ATP  consists  of  four  func¬ 
tional  types:  (1)  Executive  software,  responsible  for  control  and  execution 
of  specific  processor  tests;  (2)  Processor  test  modules,  responsible  for  the 
testing  of  AN/AYK-15A  processor  functions,  e.g.  instruction  tests;  (3)  Error 
processing,  responsible  for  the  processing  of  errors  detected  by  processor 
test  modules;  and  (4)  Interrupt  handler,  responsible  for  the  processing  of 
interrupts . 


The  ATP  was  designed  so  that  the  minimum  number  of  64K  loads  are 
required.  An  attempt  was  made  to  group  similar  '’St  modules  within  a  par¬ 
ticular  load,  for  example  memory  tests  and  menu  vrite  protect  test.  Those 
tests  that  do  not  lend  themselves  to  executive  control  were  placed  in  separate 
loads.  Table  13  contains  a  list  of  special  test  names  and  descriptions.  The 
special  tests  and  CPU  instruction  tests  are  located  in  the  LOAD  modules.  A 
list  and  description  of  the  ATP  load  modules  is  contained  in  Table  14. 

8.1.2  Executive  Software  Testing 

The  DAIS  Startup  Loader  was  also  tested.  A  set  of  application 
tasks  were  developed  which  send  messages  to  the  C&D  for  display.  The  displays 
(on  the  IMFK)  were  sufficient  to  inform  the  test  operator  of  the  state  of  the 
software  in  each  of  the  processors  after  inputs  to  the  Processor  Control  Panel. 
Several  problems  were  uncovered  in  the  Startup  Loader,  Executive's  interface 
to  the  Startup  Loader,  processor,  and  the  BCM.  After  these  problems  were 
corrected,  the  Startup  Loader  performed  as  required. 
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TABLE  13.  SPECIAL  ATP  TEST  NAMES  AND  bL  jCRM'TION. 


NAME 

DESCRIPTION 

HANGT 

Randomly  generates  and  executes  a  ( PL!  instruction  list. 

GENREG 

Verifies  capability  to  read/write  the  sixteen  general 
regi sters. 

STATREG 

Verifies  capability  to  read/write  the  status  word. 

ILL  10 

Verifies  proper  interrupt  and  fault  register  setting  upon 
execution  of  illegal  I/O  instruc*  :oris. 

ILL  INT 

Verifies  proper  interrupt  and  fault  register  setting  upon 
execution  of  illegal  CPC  instructions. 

WRPRAM 

Verifies  capability  to  read/write  the  memory  protect  RAM. 

BNCH 

Computes  processor  throughput. 

TRGTST 

Outputs  trigger  GO  discrete. 

OISCRT 

Verifies  proper  operation  of  external  discrete  lines. 

DISABL 

i 

Verifies  that  no  interrupts  are  handled  immediately  follow¬ 
ing  a  disable  instruction. 

ROMTST 

Verifies  integrity  of  the  bootstrap  ROM. 

PIOTST 

Verifies  proper  operation  of  PIO  lines. 

TIMER 

Verifies  interval  timer  values  with  and  without  interrupt' a  ; 

INTERT 

Verifies  capabilities  of  handling,  masking,  and  clearing  ; 

externally  generated  interrupts. 

INMASK 

Verifies  capability  to  read/wri^e  the  interrupt  mask. 

BCMGEN 

Verifies  capability  to  read/write  the  sixteen  BCM  general 
registers. 

BCMCN1 

Verifies  capability  to  read/write  the  sixteen  BCM  control 
registers. 

BCMCN2 

Verifies  capability  to  multiple  store,  compare  and  perform 
bit  manipulation  on  the  sixteen  BCM  control  registers. 
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TABLE  14.  ATP  LOAD  MODULE  NAMES  AND  DESCRIPTIONS 


NAME 

BOUND. OBJ 

HANG. OBJ 

ICTEST.OBJ 

INDEX. OBJ 

MEMADR.OBJ 

MEMTIM.OBJ 

MEMTST.OBd 

PWRDWN.OBJ 

LOAD1.ABS 

LOAD2.ABS 

LOADS. ABS 

L0AD4.ABS 


DESCRIPTION 

Boundary  test 
Hang  test 

Instruction  counter  test 
Index  test 

Illegal  memory  address  accessing  test 
Memory  access  timing  test 
Memory  access  and  protection  test 
Power  up/down  test 
Executive-controlled  tests  000-063 
Executive-controlled  tests  064-097 
Executive-controlled  tests  098-0D0 
Executive-controlled  tests  OD 1-111 
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8.1.3  Application  Software  Unit  Test 

Unit  testing  of  the  Application  Software  was  performed  ai  t’<  *■;  ■  ' 
computer,  a  DECsystem- 10.  At  this  level  of  testing,  the  louicai  operas  m-- 
of  each  single  task  was  tested.  Acceptance  Test  Programs  ;A7P's)  0nd  '.-r r.*-* 
support  programs  were  written  to  implement  the  testing. 

The  support  programs  required  for  the  testing  include  the  followina. 

1)  a  version  of  the  DAIS  Executive  that  runs  on  the  DECsystem-10  computer,  and 

2)  a  data  area  similar  in  function  to  the  data  base  created  by  PALEFAC. 

Each  ATP  generates  data  to  be  used  as  input  to  the  program  being 
tested.  Using  the  executive  services  it  places  the  input  data  in  the  data 
area.  The  ATP  then  invokes  the  MSW  program  being  tested.  The  MSW  program 
accesses  its  input,  executes,  and  places  its  output  in  the  common  data  area. 
Finally,  the  ATP  accesses  and  then  prints  the  results  of  the  test.  The 
testing  process  was  automated  so  that  retesting  can  be  easily  accomplished. 

8.1.4  Environmental  Model  Tests 

Acceptance  testing  was  performed  on  the  DAIS  Models  Simulation 
System  (DMSS).  The  acceptance  test  was  performed  at  three  levels: 

1.  Stand-alone  test  -  a  verification  of  responses  by 
the  DMSS  to  simulated  inputs. 

2.  Interface  and  Functional  test  -  a  verification  of 
internal  DMSS  communications  and  outputs  to  the 
DMA- 10  window. 

3.  System  test  -  a  validation  of  the  entire  DAIS  system. 

Stand-alone  testing  was  performed  for  each  individual  model.  The 
test  load  module  consisted  of  a  tailored  test  driver  and  the  model  beinn 
tested.  These  tests  were  run  on  the  DECsystein-10  computer. 

The  interface  and  functional  test  was  performed  by  insert  Min  t-o 
sensor  model  being  tested  into  the  baseline  model  set  for  all  other  model,. 
Then,  using  the  mission  scenario  generator  (MSG),  the  response  of  the  new 
model  was  recorded  and  then  compared  with  the  response  of  the  baseline  model 
set.  This  process  was  repeated  for  each  model  until  all  sensor  models  were 
individually  integrated  and  tested. 

The  acceptance  tests  revealed  several  problems  that  required 
resolution. 

8.2  Hardware  Integration  and  Test 

Incremental  integration  and  testing  was  performed,  as  each  sub¬ 
system  became  available,  until  the  system  was  fully  integrated  and  tested. 

The  key  to  the  successful  integration  and  test  was  the  development  of  exten¬ 
sive  test  software.  Four  major  test  software  programs  were  developed: 
Multiplex  System  Diagnostics  Software,  Remote  Terminal  (RT)/]nterface  Module 
(IM)  Diagnostics  Software,  Controls  and  Displays  Acceptance  Test  Program 
(ATP),  and  Performance  Monitor  Interface  Unit  ( PM  I U )  ATP. 


The  Multiplex  System  Diagnostics  were  previously  described  in  the 
Multiplex  Test  Software  Conversion  section.  Sample  Hardware  Configurations 
for  the  AN/AYK-15A  Multiplex  Diagnostics  are  shown  in  Figure  47. 

The  Remote  Terminal  (RT)/lnterface  Module  (IM)  diagnostics  exercise 
RT  and  IM  hardware  through  a  series  of  tests  and  allow  the  isolation  of 
errors.  Each  test  is  designed  for  an  RT  or  a  specific  type  of  IM.  The  diag¬ 
nostics  run  in  an  AN/AYK-15  processor  as  shown  in  Figure  48.  The  device(s) 
to  be  tested  is  attached  to  the  MIL-STD-1553B  bus.  The  user  specifies  the 
system  configuration  and  the  tests  to  be  run.  The  diagnostic's  executive 
then  sequentially  calls  each  test  selected.  Each  test  that  is  integrated 
with  this  software  is  required  to  do  the  following: 

1.  Perform  its  own  error  checking  and  reporting  and 
maintain  error  counters. 

2.  Perform  all  BCIU  control  including  interrupt 
handl ing . 

3.  Return  the  following  items  in  the  same  state  as  when 
the  test  was  called: 

a.  BCIU  registers 

b.  All  interrupt  vectors 

c.  The  BCIU  subaddress  pointers 

The  handling  of  all  errors  by  a  test  are  controlled  by  user-specifiea 
-urameters.  The  error  reporting  for  each  test  must  interface  with  these  para- 
■eters  to  allow  the  following  options: 

1.  Stop  on  errors  and  allow  the  user  to  retry  the 
failing  sequence  or  go  on  to  the  next  sequence. 

2.  Do  not  display  errors  but  maintain  counts  of  the 
different  types  of  errors. 

A  list  of  RT/IM  diagnostic  tests  in  found  in  Table  15. 

The  Multiplex  System  Diagnostics  and  the  RT/IM  Diagnostics  were 
developed  in  a  structured  and  modular  fashion  so  additional  tests  could  be 
readily  added.  Several  of  the  key  features  of  the  above  software  test  pro¬ 
grams  were: 

•  Testing  of  all  functional  areas  of  the  core  elements 
under  test. 

•  Testing  of  functional  areas  with  extensive  data 
patterns  with  error  checking  under  test  software 
control.  Many  failure  modes  were  bit  pattern 
sensitive  and/or  intermittent  requiring  a  large 
number  of  data  patterns  at  the  system  operating 
speed  in  order  to  detect  and  isolate. 
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HARDWARE  CONFIGURATION 


(This  runs  the  RT  undefined  Mode  Codes  Test,  RT 
Initialize  Terminal  Mode  Codes  Test,  and  RT  MTU 
Shutdown  Mode  Codes  Test.) 


FIGURE  47.  SAMPLE  HARDWARE  CONFIGURATIONS 


Fir'PE  48.  BLOCK  DIAGRAM  M  HARDWARE  "SEP  BY  ThE  Rl/IM  DIAGNOSTICS 


i ABLE  lb.  KI/'iM  U1A(  .NOST ICS  TESTS 


TEST 

NUMBER 


TEST  NAME 


Initial  polling 


spare 


Spare 


Spare 


Spare 


RT  undefined  mode  codes 


RT  initialize  terminal  mode  codes 


RT  MTU  shutdown  mode  codes 


Spare 


Spare 


IT 


Spare _ 

Single-ended  discretes  in/out 


11 


IT 


ing 

Differential  discretes  in'/out 


13 


Switch  closure  in/out 


14 


IT 

3E 


DC  Analog  in/out 


AC  Analog  in/out 


Spare 


17 


Spare 


18 


Spare 


19 

TO 


Momentary  in 
Synchro  in/out 


Serial  in/Serial  out  (normal  operation) 

Serial  in/Serial  out  (parity  error  "operation) 


71 

7T 


24 


Remote  terminal  to  Remote 


25 


Spare 


26 


Spare 


27 


Spare 


7T 


Spare 


29 


Spare 


30 

TT 


Spare 


Spare 


IT 


Spare 
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V 

•  > 

1 


•  Segmenting  test  software  to  functional  areas  of  the 
hardware  under  test.  T  is  f  ac  .  !  f  ’  h  '  >■<!  ,  t  •..■icm.i  1  'clr 
t  ion  ny  allowing  the  tec (•:.**•»•  uo>  f:.«  option  o< 
running  test  softwate  on  the  failing  egmei.r  ch/. 

•  Providing  stop  on  error  and  loop  on  section,  sub¬ 
section,  and  failing  data  pattern.  This  facilitated 
problem  isolation  and  provideo  conditions  under  which  a 
problem  (even  intermittent)  could  be  scupeo1  or  traced 
with  a  logic  analyzer. 

•  Generating  data  patterns  at  execution  rates  at  least 
comparable  to  the  normal  operation  rate  for  tne  equip¬ 
ment  under  test.  Many  failure  modes  woe  induced  only 
at  or  near  maximum  data  rates  because  of  noise,  signal 
line  "ringing"  or  "cross  talk"  and  other  high  speed 
phenomena. 

t  Sequencing  through  all  phases  of  the  lest  repetitively 
(looping)  with  error  checking.  Capability  allowed 
equipment  testing  for  thermal,  noise,  and  other  inter¬ 
mittent  errors,  and  provided  a  high  decree  of  confidence 
when  equipment  operated  successfully  for  extended 
periods  of  time. 

•  Supporting  system  verification  prior  to  loading  and 
running  mission  software,  and  supporting  problem 
detection  and  isolation  during  mission  software  chedout 
and  predemonstration  phases.  System  integrity  was 
established  before  loading  mission  software  so  mission 
software  debugging  would  not  be  plagued  with  hardware 
problems. 

•  Providing  structured  and  modular'  test  software  to 
facilitate  development  in  stages  and  to  allow  inclusion 
of  test  software  from  various  sources. 

The  C&D  ATP  performs  two  major  functions  in  testing  the  C&’J.  r  i •  . 

if  Handles  the  interface  between  the  CAP  devices  end  the  test  so*twir»>.  Tv  e 
interface  programs  are  called  EQU IP's.  Secondly,  it  controls  execution  by 
prompting  the  user  and  performs  the  actual  tests,  "able  16  briefly  describes 
tne  programs  comprising  this  ATP.  figure  4.1  presents  the  hardware  configura¬ 
tions  used  iri  performing  the  tests. 

The  AN/AYK-lbA  Performance  Monitor  Interface  Ur.  it.  (PMIU)  Acceptance- 
Test  Program  is  an  integral  part  of  the  PMIU  qud  1  ‘  ication  package.  Ttie  I’M  1 1: 
ATP  consists  of  three  functional  Types:  (■)  Interface  test  software,  respons¬ 
ible  for  the  testing  of  the  PMIU/PDP-il  interface;  (2)  Control  and  monitor 
test,  responsible  for  the  testing  of  PM I ; i  control  gnu  monitor  functions,  (3) 
Post  run  editor,  responsible  for  the  formatting  and  processing  of  data  gathered 
during  PMIU  testing. 

The  ATI  was  designed  sc  as  to  allow  user  directives  via  interactive 
or  disk  file  inputs.  This  will  facilitate  the  use  of  the  PMIU  ATP  for  AYK-lbA 
software  development.  F  igure  bC  shews  the  PVT  system  and  interface  require¬ 
ments.  Prior  *o  execution,  the  AT  software  must  be  loaded  into  tne  PDP-11 
with  all  appropriate  devices  as  shown  in  Fianro  60. 
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TABLE  16.  CONTROLS  AND  DISPLAYS  ATP 


Task 


EQUIPS: 

QPOIIMFK' IN 
QP02IMFK1 IN 
QP03 IMFK 'ARBIT 
QP04DEK1* IN 
QP05DEK1'ARBIT 
QP06DEK1' ARBIT 
QP07MMP' IN 
QP08MMP' IN 
QP09HMP'ARBIT 
QP100EK2 1  IN 
QP11DEK2' IN 
QP12DEK2' ARBIT 
QP13MPDG1 1  IN 
QP14MPDG1 ' IN 
QP15MPDG1* ARBIT 
QP16MPDG2' IN 
QP17MPDG2 ' IN 
QP18MPDG2'ARBIT 
QP19MFK' IN 
QP20MKF1 IN 
QP2IMKF1 ARBIT 
QP22SA81 IN 
QP24SA9' IN 
QP26SA11 ' IN 
QP 50 I MFK1 OUT 
QP51MMP' OUT 
QP52SA6' OUT 


Description 


IMFK  input  equip  for  RT  16. 

IMFK  input  equip  for  RT  9. 

IMFK  input  arbitrator  task. 

DEK-1  input  equip  for  RT16. 

DEK-1  input  equip  for  RT  9. 

DEK-1  input  arbitrator  task. 

MMP  input  equip  for  RT  16. 

MMP  input  equip  for  RT  9. 

MMP  input  arbitrator  task. 

DEK-2  input  equip  for  RT16. 

DEK-2  input  equip  for  RT  9. 

DEK-2  input  arbitrator  task. 

MPDGl  status  input  equip  for  RT16. 
MPDGl  status  input  equip  for  RT  9. 
MPDGl  status  input  arbitrator  task. 
MPDG2  status  input  equip  for  RT16. 
MPDG2  status  input  equip  for  RT  9. 
MPDG2  status  input  arbitrator  task. 
MFK  input  equip  for  RT16. 

MFK  input  equip  for  RT  9. 

MFK  input  arbitrator  task. 

SA8  input  equip  for  RTl6and  RT  9. 
SA9  input  equip  for  RTI6  and  RT  9. 
Determine  the  state  of  the  PCP. 
Displays  data/pages  on  the  IMFK. 
Outputs  light  commands  to  the  MMP. 
SA6  output  equip  for  RT16and  RT  9. 


TEST  SOFTWARE: 
CPOOINIT 

CPOITEST' SELECT 

CP02CD' TEST 


Initializes  data  and  schedules  equips 
calls  CP01  to  begin  execution. 

Allows  the  user  to  select  major  test 
categories  and  then  schedule  the 
selection.  Currently  only  CP02  is 
available  (C  &  D  test). 

Allows  the  user  to  select  which  C  &  D 
device  he  wishes  to  test  and  then 
schedule  the  selection. 
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TABU  lb.  CONTROLS 


Task 

TEST  SOFTWARE  Cont. 
CP05MMP' Test 

CPIOIMFK' TEST 

CP15MFK' TEST 

CP20DEK1 1  TEST 
CP250EK2 ' TEST 
•CP30SCU'TEST 

CP31SCU' KEY'TEST 

CP32SCU' TRIGGER 'TEST 
CP33SCU' ROCKER1 TEST 
CP34SCU' CONTROLLER' TEST 

CP35AP' TEST 

CP36ARM' PANEL'TEST 
CP37MASTER' ARM’ TEST 
CP38SALV0' SWITCH* TEST 
CP40HU 

CP45MPDG' KEY' TEST 
CP46VSD' KEY'TEST 


Description 

Turns  on/off  MMP  lights  v/hen  respect¬ 
ive  key  hits  are  made. 

Turns  on/off  IMFK  lights  when  respect¬ 
ive  key  hits  are  made.  Displays 
all  applicable  characters  on  CRT. 

Turns  on/off  MTK  lights  when  respect¬ 
ive  key  hits  are  made.  Activates 
all  back  light  displays. 

Echoes  back  on  IMFK  the  value  entered 
on  the  DEK1. 

Echoes  back  on  IMFK  the  value  entered 
on  the  DEK?. 

Allows  the  user  to  select  which  SCO 
device  he  wishes  to  test  and  then 
schedule  the  selection. 

Turns  on/off  SCU  lights  when  respect¬ 
ive  key  hits  are  made. 

Displays  trigger  level  on  IMFK. 

Displays  rocker  position  in  IMFK. 

Displays  the  numeric  value  of  the  SCU 
controller  and  terminates  upon 
hitting  the  controller  switch. 

Allows  the  user  to  select  which  arma¬ 
ment  panel  device  he  wishes  to 
test,  and  then  schedules  the  select¬ 
ion. 

Displays  the  states  of  Ap  switches  on 
the  IMFK. 

Displays  the  state  of  the  master  am  i 

switch  on  the  IMFK.  ' 

Displays  the  state  of  the  salvo  switch 
on  the  IMFK. 

Displays  the  state  of  the  HUD  switches 
of  the  MMP  on  the  IMFK. 

Allows  the  user  to  select  which  MPDG 
display  he  wishes  to  test. 

Turns  on/off  V5D  lightswhen  respect¬ 
ive  key  hits  are  made  and  displays 
range  switch  state  on  IMFK. 
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TABLE  16.  CONTROLS  AND  DISPLAYS  ATP  (Con't) 


» 

| 

» 

i 

I 

l 

I 

I 

5 


Task 


Description 


TEST  SOFTWARE  Cont. 
CP47HSD' KEY'TEST 

CP48MPD1' KEY' TEST 

CP49MPD21 KEY1 TEST 

CP50PCP'TEST 

CP51PCP1 INPUT1 TEST 
CP52PCP1 OUTPUT1 TEST 

CP55STICK1 TEST 
CP60THR0TTLE 1  TEST 
CP65RT1 CONTROL' TEST 

CP70MP 

CP71BOOT'MPDG 

CP72MPDG1 STATUS 
CP73WAYP01NT 

CP74TABLE'CONTRL 
CP75TASK1 ASSIGNMENT 
CP76MASTER'MODE 


Turns  on/off  HSD  lights  when  respective 
key  hits  are  made  and  displays  range 
switch  state  on  IMFK. 

Turns  on/off  MPD1  lightswhen  respect¬ 
ive  key  hits  are  made  and  displays 
range  switch  state  on  IMFK. 

Turns  on/off  MPD2  lightswhen  respect¬ 
ive  key  hits  are  made  and  displays 
range  switch  state  on  IMFK. 

Allows  the  user  to  test  either  the 
input  or  output  function  of  the  PCP. 

Displays  the  status  of  the  PCP  switches. 

Turns  on/off  PCP  lights  in  a  pre-defined 
order.  Also,  forces  the  processor 
to  issue  PCP  latch  commands,  which 
may  be  tested  by  the  user. 

Displays  the  status  of  the  stick 
switches  and  trigger  on  the  IMFK. 

Displays  the  status  of  the  throttle 
switches  on  the  IMFK. 

Allows  the  user  to  select  which  RT 
is  primary  and  whether  the  IMFK 
or  MFK/MPD1  display  is  to  be  used. 

Allows  the  user  to  select  which  function 
of  the  MPDG  is  to  be  tested. 

Allows  the  user  to  boot,  load  and 
execute  an  MPDG. 

Displays  the  status  of  the  MPDG. 

Allows  the  user  to  select  the  various 
options  concerning  the  activation 
and  control  of  the  map  driver. 

Allows  the  user  to  read,  modify  and 
display  text  tables. 

Assigns  tasks  to  MPDG  displays  as  a 
function  of  user  input. 

Allows  the  user  to  select  various  data 
sets  that  are  used  in  MPDG  displays. 
Also  allows  symbology  to  be  turned 
on/off. 
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TABLE  16.  CONTROLS  AND  DISPLAYS  ATP  (Lon't) 


Task 


Description 


TEST  SOFTWARE  Cont. 
CP90NAV ' UPDATE 

CP95WAYPT' DISPLAY' TEST 

CP96DECLUTTER' TEST 

DP51MAPUPDATE 


Calculates  aircraft  position  based  on 
its  velocity  vector  and  current 
position. 

Allows  the  user  to  test  the  various 
functions  associated  with  the  way- 
point  display. 

Allows  the  user  to  select  various  de¬ 
clutter  modes  and  observe  the  re¬ 
sult  on  the  MPDG  display. 

Determines  which  map  chips  need  to 
be  loaded  and  sends  appropriate 
data  to  map  driver. 
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CONFIGURATION  1: 


CONFIGURATION  2: 


MUX  BUS 


MUX  BUS 


CONFIGURATION  3: 


MUX  BUS 


CONFIGURATION  4: 


AN/AYK-15 


*  PRIMARY  RT 

FIGURE  49. 


BCIU 


MUX  BUS 


RT  16 


RT  9 


HARDWARE  CONFIGURATIONS  FOR  TESTING 
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VT52  COMPATIBLE  CRT 


|  UN  I  BUS 

FIGURE  50.  PMIU  INTERFACE  DIAGRAM 


The  System  Readiness  Test  (SRT)  is  designed  to  quickly  test  the 
operating  condition  of  the  DAIS  Software  Test  Stand  (STS)  or  the  Integrated 
Test  Bed  (ITB).  The  following  systems  are  tested: 

1.  PMC  and  SSDF  PDP- 1 l/40s 

2.  Console  Intelligence  Units  (CIU) 

3.  Super  Control  and  Display  Units  (SCADU) 

4.  Remote  Terminals  (RTs) 

5.  Universal  Remote  Terminals  (URT) 

6.  AN/AYK-15  processors  and  BCIUs  or  AN/AYK-15A 
prccessor/BCIs 

7.  Bus  Monitors 

8.  Performance  Monitor  Interface  Units 

9.  Evans  and  Sutherland  System 

10.  DAIS  Controls  and  Displays 

The  following  group  of  programs  forms  the  SRT: 

1.  Control  file  that  runs  with  the  PMC  software  or 
the  PMIU  software 

2.  Assembly  language  programs  that  run  on  the  AN/AYK-15 
or  AN/AYK-15A 

3.  A  FORTRAN  program  that  runs  on  the  DECsystem-10 

4.  Post  run  edit  files  that  run  on  the  PMC  PDP-11/40 

The  programs  work  together  to  perform  a  quick  check  on  the  above  hardware  in 
less  than  15  minutes;  therefore,  the  DAIS  users  could  run  this  software  every 
orning  and  before  demonstrations  to  insure  the  DAIS  systems  are  in  working 
order. 

8.4  Results  of  Testing  AN/AYK-15AS  from  Two  Contractors 

This  section  describes  the  tests  that  were  performed  on  the 
Westinghouse  and  Sperry  Univac  AN/AYK-15AS  during  1980  and  early  1981.  A 
summary  of  the  test  results  for  each  vendor  and  a  summary  of  the  compatibility 
between  the  two  implementations  of  the  AN/AYK-15A  are  included. 

8.4.1  Inventory  of  Tests 

The  tests  performed  on  each  AN/AYK-15A  include: 

•  Execution  of  the  Bootstrap  Loader 

•  3-Processor  Executive  Acceptance  Test  Program 

•  Processor  Acceptance  Test  Program 

•  Multiplex  System  Diagnostics 

•  Bus  Control  Module  (BCM)  Error  Response  Tests 
t  Input/Output  and  Internal  Tests 

t  Miscellaneous  Tests 


All  of  the  tests  were  performed  with  both  AN/AYK-15/BCIUs  and  other  AN/AYK-15AS 
from  both  vendors. 


b .  4 . 1 . 1  Bootstrap  Loader 


The  Bootstrap  Loader  was  used  to  load  all  of  the  ISA  test  soUwa>r- 
programs  from  the  PDP-ll/URT  to  the  ISA  processor  memory  over  the  1SS3B 
multiplex  bus  as  illustrated  in  figure  51.  The  software  program  in  the  PL)r- ,  1 
was  used  to  simulate  a  mass  memory  device  on  the  multiplex  bus.  Software 
resident  in  the  upper'  core  of  the  15A  memory  was  then  used  to  initiate  the 
BCM  as  a  bus  controller  and  transfer  application  and  test  software  and  data 
from  the  mass  memory  device  to  the  15A  processor  memory.  64K  words  can  be 
transferred  in  approximately  15  seconds  using  this  technique. 

8 . 4 . 1 . 2  3-Processor  Executive  Accepta nee  Tes t  Program  (AT P ) 

The  3-Processor  Executive  ATP  with  the  AN/AYK-15A  as  the  unit  under 
test  (UUR)  was  executed  using  the  test  configuration  shown  in  figure  51. 

a. 4. 1.3  Processor  Acceptance  Test  Program  (ATP) 

The  Processor  ATP  (15A,  1750)  was  executed  using  the  test  config¬ 
uration  shown  in  figure  52.  This  set  of  software  programs  was  u^ed  to  test 
the  entire  instruction  repertoire  and  functional  capability  of  the  15A  pro¬ 
cessor. 

8 . 4 . 1 . 4  Multiplex  System  Diagnostics 

The  Multiplex  System  Diagnostic  tests  were  executed  using  tne  tes. 
configuration  shown  in  Figure  53.  The  software  programs  were  used  to  test 
the  Master  and  Remote  mode  functional  requirements  of  the  !5A  BCM  and  the  5rM/ 
processor  interface.  The  software  in  the  PDP-11  was  used  to  simulate  multiple 
KTs  via  the  URT. 

8.4. 1.5  BCM  Error  Response  Tests 

BCM  Error  Response  tests  were  conducted  to  test  the  performanct  ot 
me  15A  BCM  when  errors  occur  on  the  multiplex  bus  and  were  accomplished  using 
me  test,  configuration  shown  in  rigure  54. 

.4.1.6  Input/Output  (I/O)  and  Internal  Tests 

I/O  and  Internal  tests  were  conducted  to  test  the  input  and  output 
requirements  of  the  AN/AYK-15A  (e.g.,  programmed  input/output,  direct  memory 
access,  interrupts,  etc.)  and  to  verify  the  resolution  of  unique  problems 
encountered  during  the  debugging  stage  of  the  15As.  The  test  configuration 
for  the  I/O  tests  is  shown  in  Figure  55. 

8 . 4 . 1 . 7  Miscellaneous  Tests 


Investigations  and  measurements  were  made  to  obtain  additional  infor¬ 
mation  on  the  performance  of  the  AN/AYK-15As.  Of  particular  interest  are  the 
measurements  of  memory  access  times  with  CPU,  DMA  and  BCM  memory  contention  on 
the  Sperry  Uni  vac  AN/AYK-15A  and  the  measurements  of  the  Master  mode  BCM  start 
and  stop  times  for  both  the  Westinghouse  and  Sperry  Univac  AN/AYK-15As.  A 
summary  of  these  measurements  is  given  in  section  8. 5. 2. 3. 


FIGURE  51.  TEST  CONFIGURATION  FOR  THE  3-PROCESSOR  EXECUTIVE  ATP 


ITST  CONr; DURATION  I  OR  THE  ONE- PROCESSOR 


FIGURE  53.  TEST  CONFIGURATION  FOR  MULTIPLEX  DIAGNOSTIC  TESTS 


FIGURE  54.  TEST  CONFIGURATION  FOR  BCM  ERROR  RESPONSE  TEST 


•PIO 

DAIS  I/O  • EXT  INTERRUPTS  AN/AYK-1 5A  AN/AYK-1 5A 


FIGURE  55.  TEST  CONFIGURATIONS  FOR  THE  I/O  TESTS 


o.4.2  Kesui  is  of  iebtiiiij 

I  '  is  SOCtll.L  S'.ilillldl  ’ZCj  t'it*  VCI'd  I  1  ’  '•  l'  *l.'l  .M’St'V 

and  Sperry  pi  i  vac  AN/A’tk- 1  •)/'■'  .  1  ti<  se  rf“,uir  ,  :r  e  i,<  Ik-  '• 

idte  units  a  t  ter  several  i  terjtion-,  o*  ;  ruflei;,  i  velal  ion  mil  ft- pa  i  r .  cpt •  : :  1 
test  results  associated  wi  th  the  indiv  idu-i ,  units  /,e>  <-  O'/cun-ented  a  u-r  i<  , 
of  informal  test  reports. 

8.4.2. 1  Test  Results  for  Nest  mghous'  AN/AYK- 15A 

Tie  Bootstrap  Loader  and  the  1 -Processor  l.Aecutivc-  AT !'  were  executed 
without  incident,  ~ables  17  through  l'l  indlcaie  tne  results  of  the  Processot 
ATP,  Multiplex  System  Diagnostics,  and  BCM  frrur  Pt-sp  n^e  t-  ts,  r  _spect  ivel 
that  failed  on  the  Westinghouse  AN/  AY  l  -  !!.-A.  Pule  7  ;  ••uininar  izes  tne  results 
of  the  I/O  test; . 

3. 4. 2. 2  Test  Results  for  Sperry  Uni  vac  AN/A (K- 15A 

The  Bootstrap  loader  and  the  3-Processor  FTec.itive  ATP  were  executed 
without  incident.  Tables  21  through  2.1  indicate  tne  results  of  the  Processor 
ATP,  Multiplex  System  Diagnostics,  and  BCM  Lrror  Response  tests,  respectively, 
that  failed  on  the  Sperry  Uni  vac  AN/AYK-15A.  Table  24  summarises  the  results 
of  the  I/O  tests. 

8 . 4 . 2 .  .3  Results  of  Miscellaneous  Tests 

Tne  results  of  memory  access  times  are  summarized  in  TatK-  25  and 
were  measured  on  the  Sperry  Uni  vac  AN/AYK  ISA  prototype  early  in  May  of  198';. 
ihe  results  of  measurements  taken  on  tne  AN/AYtl- 15A  from  botn  vendors  for  the 
Master  mode  BCM  start  and  stop  times  under  various  conditions  are  summarize! 
m  Table  26. 

8.4.3  AN/AYK- 15A  Compatibility 

One  of  the  original  goals  cited  for  tne  dual  source  procurement  of 
the  AN/AYK-15A  digital  processor  was  to  ascertain  the  feasibility  of  procu' :n  . 
compatible  1 5 As  from  two  vendors  utilizing  different  mini ementat ions  to  nee* 
tne  sane  requirements.  To  achieve  this  result,  the  development  spec i fir  at  >  ;n 
u . i  netessari 1 y  be ; 

1)  general  enough  to  support  rather  thui  supplant  the 
design  and  implementation  of  the  AN/AV K- 15A,  and 

2)  specific  enc  gn  to  avoid  multiple  interpretations 
and  uticl early  specified  reouit enter. ts  that  lead  to 
incompatible  performance. 

The  addition  of  the  specif ication  changes  was  made,  in  part,  to  improve 
the  specification  and  eliminate  those  areas  of  tne  specification  where  incom¬ 
patibility  issues  had  been  observed  between  the  two  vendors. 

A  simple  measure  o*  compatibility  between  tne  Westinghouse  and 
Sperr /  Univ.it  AN/ AY k- , BAs  involves  the  substitution  of  either  15A  into  a 
system  eon  fi  .jurat  ion  without,  oranges  to  system  performance  and  without 
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TABLE  17.  WESTINGHOUSE  AN/AYK-15A  SUMMARY 
OF  FAILING  PROCESSOR  TESTS 


TEST  NAME 

REASON  FOR  FAILURE 

FSB 

Results  not  accurate  to  the  least 

FS 

significant  bit  on  floating  point 

FSR 

subtracts. 

FDB 

Results  not  accurate  to  the  least 

FD 

significant  bit  on  floating  point 

FDR 

divides. 

EFD 

EFDR 

BRX 

Results  not  accurate  to  the  least 
significant  bit  on  floating  point 
subtracts  and  floating  point  divides. 

HANGT  TEST 

Execution  of  an  illegal  opcode  sometimes 
causes  CPU  Memory  Protect  and  Illegal 
Instruction  bits  to  be  set  in  the  Fault 
Register-depending  on  the  contents  of 
the  general  registers. 

BCMGEN 

Some  of  the  BCM  control  and  general 

TEST 

registers  are  tied  together. 

Illegal 

Execution  of  an  illegal  I/O  instruction 

I/O  Test 

(output  opcode  with  an  input  operand) 
that  deals  with  the  BCI  control  register 

0  or  BCI  general  register  0  causes  BCI 
to  generate  an  interrupt  when  the  GO  bit 
in  the  PCR  is  zero. 
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TABLE  i8.  *i:,TING;)U.>i  AN/AV- 1BA  SiTV-'A;  . 

OF  MULT  IF-’LL X  DIAGNOSTIC  F:  J:, 


H 

TEST  NAME 

MAS  ILF 

"'EM!;!  • 

IN1T 

Initial izat ion 

P 

P 

0 

Initial  Polling 

P 

P 

2 

BCI  Undefined  Mode  Commands 

P 

P 

3 

EC I  MTU  Shutdown  Mode  Commands 

P 

P 

4 

Ell  Mode  Commands  With  Interrupts 

F(Note  I ) 

P 

5 

RT  Undefined  Mode  Commands 

P 

N/A 

6 

RT  Initialize  Terminal  Mode  Commands 

p 

N/A 

7 

RT  MTU  Shutdown  Mode  Conmands 

P 

N/A 

8 

URT  Mode  Commands 

P 

N/A 

9 

Master  Asvnc  to  Remote  Sync  Transfers 

P 

P 

10 

Master  Sync  to  Remote  Asvnc  Transfers 

P 

P 

11 

BCM  State  Transitions 

P 

N/A 

12 

BCM  Internal  Operations 

P 

N/A 

13 

Remote  Transmission  Lockout  Flag 

P 

P 

14 

Remote  Reception  Lockout  Flag 

P 

P 

15 

Lockout  Flaq  Set/Reset 

P 

r? 

16 

Master  to  Remote  Synchronous  Transfers 

P 

P 

17 

Master  to  Remote  Synchronous  Transfers 

P 

p 

18 

Remote  to  Remote  Synchronous  Transfers 

P 

P 

19 

Master  to  Remote  Synchronous  Transfers 

P 

P 

20 

Remote  to  Remote  Synchronous  Transfers 

P 

P 

21-24 

Mass  Memory  Tests 

- 

- 

25 

Remote  BCI  Self-Test 

P 

P 

26 

Master  BCI  Sel f-Test 

P 

N/A 

27 

Lockout  Flag  Duration 

P 

P 

23 

Lockout  Flag  on  Receive 

P 

P 

29 

Lockout  Flaq  on  Transmit 

P 

r 

30 

MTU  Shutdown  Command 

F(Note  2) 

p 

31 

Bus  Active  Bit 

P 

p 

32 

Bus  List 

r. 

r 

y'BADDRESS 

FOR  MODE 

COOES 

0 

r 

p 

31 

P 

p 

MOLT  I PLEX 

BOS 

A 

P 

p 

T 

P 

p 

1 


I 


P:  Pass  Not  Pun 

F:  Frill  N/A:  No*-  Applicable 

No  to  • :  -psiv  i  f  ication  1  ntcr; -»t  ca  Mon  Problem  (See  section  8.5.3) 

Note  2:  Westi nghouse  15A  does  not  incorporate  SCN2  changes  to 
SA  421  205 
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TABLE  19.  UESTINGHOUSE  AN/A/K-lM  liLM  LrtnUk  kLjhL'I^L  PROBLEMS 
MESSAGE  |  INDUCED  ,  EXPECTED  j  ACTUAL 
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Remote  Controller-  High  bit  count  in  Command  ignored  intermittently  sets 

to-Terminal  command  word  data  parity  error  and 


TABLE  19.  WESTINGHOUSE  AN/AYK-15A  BCM  ERROR  RESPONSE  PROBLEMS  (Con't) 


TABLE  20.  WESTINGHOUSE  AN/AYK-15A  SUMMARY  OF  I/O  AND  SPECIAL  TESTS 


FABLL  iil. 


UNI  VAC  AN/ A VC- lb A  GUMMAKY 
OF  FAILING  LKOCLbudk  TLL.TL 


Li  ASNf.  F OF:  i  A;  I 


>ENCHMAkK 


MLMTST 


HANG 

HANG! 


OB 

BRX  (DBV; 
I M  (DIN ) 


Processor  throughput  measured  at 
only  385  KOPS. 

The  CPU  memo ry  protect  i i.terrupt 
is  posted  after  execution  o'  t;". 
next  i n : true t. i cn .  This  delav 
causes  the  software  to  astute  tha 
write  protect  die  not  occur  and 
displa;.  an  error  message. 

Th‘-  de  i  av  in  posting  of  :»«»  CPI 
-■ernory  protect  interrupt  'level  I 
interrupt)  causes  oroL-,le’--s  .-.her, 
the  next  instruction  a 'so  causes 
a  level  1  interrupt  which  is 
posted  immediately.  A  1 

interrupt  is  therefore  <:ene*'a* r  d 
on  top  of  another  level  1  ir.'err... 
which  causes  the  software  t.<- 
’.uanc- up  in  the  interrupt 
handl  or. 

The  CPU  is  not  ceneratini  a  fixed 
point  interrupt  for  the  smallest 
negative  number  (8000  or  80000000) 
divided  by  the  largest,  negative  m, 
ben  (ff-Fr  nr  FFFFF'-'FT). 


TABLE  22.  UNIVAC  AN/AYK-15A  SUMMARY 


OF  MULTIPLEX  DIAGNOSTIC  TESTS 


wmm 

TEST  NAME 

MASTER 

REMOTE 

INI  T 

Initial ization 

P 

P 

0 

Initial  Polling 

P 

P 

2 

BC1  Undefined  Mode  Commands 

P 

P 

3 

BCI  MTU  Shutdown  Mode  Commands 

P 

P 

4 

BCI  Mode  Commands  With  Interrupts 

P 

P 

5 

RT  Undefined  Mode  Commands 

P 

N/A 

6 

RT  Initialize  Terminal  Mode  Commands 

P 

N/A 

7 

RT  MTU  Shutdown  Mode  Conmands 

P 

N/A 

8 

URT  Mode  Commands 

P 

N/A 

9 

Master  Async  to  Remote  Sync  Transfers 

P 

P 

10 

Master  Sync  to  Remote  Async  Transfers 

P 

P 

11 

BCM  State  Transitions 

F(Note  1) 

N/A 

12 

BCM  Internal  Operations 

P 

N/A 

13 

Remote  Transmission  Lockout  Flag 

P 

P 

14 

Remote  Reception  Lockout  Flag 

P 

P 

15 

Lockout  Flag  Set/Reset 

P 

P 

16 

Master  to  Remote  Synchronous  Transfers 

P 

P 

17 

Master  to  Remote  Synchronous  Transfers 

P 

P 

18 

Master  to  Remote  Sybchronous  Transfers 

P 

P 

19 

Master  to  Remote  Synchronous  Transfers 

P 

P 

20 

Master  to  Remote  Synchronous  Transfers 

P 

P 

21-24 

Mass  Memory  Tests 

- 

- 

25 

Remote  BCI  Self-Test 

P 

P 

26 

Master  BCI  Self-Test 

P 

N/A 

27 

Lockout  Flag  Duration 

P 

P 

28 

Lockout  Flag  on  Receive 

P 

P 

29 

Lockout  Flag  on  Transmit 

P 

P 

30 

MTU  Shutdown  Command 

P 

P 

31 

Bus  Active  Bit 

P 

P 

SUBADDRESS 

FOR  MODE 
CODES 

0 

P 

P 

31 

P 

P 

MULTIPLEX 

BUS 

A 

P 

P 

B 

P 

P 

P;  Pass 
F:  Fail 

Note  1: 


Not  Run 

N/A:  Not  Applicable 


BCM  does  not  generate  an  interrupt  to  the  processor 
for  one  internal  operation  (minimal  impact) 
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UNI V At  AH/AYK-I5A  BCM  ERROR  RESPONSE  PROBLEMS 


i  ther 
vim- 


TABLE  24.  UNIVAC  AN/AYK-15A  SUMMARY  OF  I/O  AND  SPECIAL  TESTS 


1 


TABLE  25.  UN ;  VAC  Ah  /  AYh  -  i  5A  MtMUK’V  Ac ' t ' 


CONDITION 

NUMB  LB  .1  MLMOBV  ACcCSTlC  :'l  -  Mil  K'i',i  C1  .NO 

CPU  BCI  DMA  IOTAL 

CPU  only 

1 . 02  -  -  i  .  yjc. 

BCI  only 

NOT  TEST L U * 

DMA  only 

.  /  ■  '  ‘  t , 

CPU  &  BCI 

0.V5  0.0U  -  1.0’. 

CPU  &  DMA 

0.B2  -  3.,.-.  1.07 

BCI  &  DMA 

NOT  TENDED* 

CPU,  BCI  &  DMA 

0 . / 1  u . oo  0 . u A  1.09 

*BCI  will  not  run  unless  CPC  is  ;  wninq 

.Bdsjs. 

•  CPU  performing  a  series  of  double  io.-.U.  double  a  so, 
double  store  instructions. 

t  BCM  performing  a  series  of  no-op  instructions. 

•  DMA  write  operations  pericrisea  repetitively  using 
DAIS  I/O  exerciser. 
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TABLE  26.  MASTER  15A  BCM  START  AND  STOP  TIMES 
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•  Exception  Response  -  There  is  some  ambiguity  in  the 
specification  regarding  the  setting  of  the  RDE  bit  in 
the  ISR  when  a  remote  transmitter  is  busy.  The 
Westinghouse  15A,  upon  receiving  a  busy  status  response 
from  a  remote  transmitter,  does  not  expect  data  and, 
therefore,  sets  only  the  XBSY  bit  in  the  ISR.  The 
Univac  15A,  on  the  other  hand,  continues  to  expect  data 
and,  therefore,  sets  bcth  the  XBSY  and  RDE  bits  in  the 
ISR.  Since  the  ICR  codes  for  this  type  of  response  are 
identical  in  either  case,  the  problem  becomes  trivial. 

However,  multiple  status  word  exceptions  and/or  errors 

on  the  bus  (see  Tables  19  and  23)  can  lead  to  incompatible 
status  response  handling  in  the  master  15As. 

•  Power-On  Initialization  -  Global  memory  protection  of  the 
15A  processor  after  a  power-on  initialization  or  a  user 
console  clear  command  is  treated  differently  in  the  two 
implementations  of  the  AN/AYK-15A.  SCN  2  to  SA  421  205 
clarifies  the  proper  requirements. 

d . o  Fiber  Optics  Multiplex  System  Integration  and  Test 

The  AVSAIL  fiber  optics  integration  plan  was  initiated  to  inves¬ 
tigate  the  feasibility  of  time-division  multiplexed  communication  over  a 
fiber  optic  bus.  Because  of  its  inherent  qualities  (i.e.  noise  immunity, 
security,  electrical  isolation,  low  loss  and  high  bandwidth),  fiber  optics 
was  chosen  as  a  desirable  transmission  medium  for  MIL-STD-1553B. 

The  successful  completion  of  the  AVSAIL  Fiber  Optics  integration 
plan  would  make  possible  the  operation  of  real-time  software  simulation 
supported  by  an  optically  coupled  network  of  up  to  32  MIL-STD- 1 553B  devices. 

Interfacing  between  the  MIL-STD- 1553B  Bus  and  an  optical  network 
requires  several  considerations.  Among  them  is  the  conversion  of  the  bi-st^te 
(one,  zero)  optical  format  to  a  tri-state  (plus,  minus  and  zero)  Manchester 
format.  Because  of  this  state  transition,  another  consideration  is  intro¬ 
duced:  delay.  In  order  to  discern  between  an  end  of  message  or  a  command 
(status  word  tol  lowed  by  a  data  sync),,  the  optical  receiver  must  wait  a  finite 
amount  of  time  before  deciding  whether  the  Manchester  output  should  return  to 
zero  (end  of  message)  or  remain  at  a  minus  value  (data  sync  detected). 

Manchester-to-optical  encoding  is  performed  by  modulating  the 
optical  tra:  fter  with  the  positive  half  of  the  Manchester  waveform  (plus, 

zero  convert  one,  zero). 

The  nardware  implementation  of  this  plan  has  been  broken  down  into 
.•■■/era!  different  tasks  assigned  to  various  contractors.  Singer  Kearfott  was 
•  ••  i  **••:  to  provide  optical  translator  units  capable  of  interfacing  any 

future  MIL-STD- 1553B  device  to  a  fiber  optic  network.  Westinghouse 

■  :.cU'd  separate  efforts  to  produce  embedded  fiber  optic  inter- 

■  ■  •■•  “  Ark  -  ISA  processors.  Under  a  separate  contract,  IBM 

tnat  effectively  ties  all  available  optical 


r 
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•perry  -1miv.il  prov  i  Jet.;  i.v<  ,.ro-t  .<t  yi  ••  .t. e  .  n.o.t.!*- 

Al  ft'Au  ‘or  evu  1  uat  ion .  1  nodule'  .-.■•-i-,  . :  .  i  i-i. 

tested  tut'  opt  ical  output  power  anti  ;  it  i.rii.-r  rate  ,  L ,  ,  vet  .  p'  i  <!  .  . 

Ai  tno-.yjn  tne  on  i  vac  modules  nad  acceutaLie  optica  i  i.i two’  ;  -j.v  • 
a  discontinuity  was  notec  in  the  Lit  ert  or  rate  ceasur or  out . 

With  both  modules,  the  Ltk  was  acceptable  in  Loth  the  .  --r  .in-: 
lower  optically  received  power  ranges,  but  a  total  loss  of  lour  .uicafion  wo 
observed  between  them. 

After  verifying  tne  existence  01  the  problem  with  the  a  *•* ,  t  ue 
modules  were  returned  to  univac  tot  analysis.  fne  mac. lies  were  j t  i  1  1  ir- - 
available  for  ^testing  at  the  termination  of  this  contract. 

At  the  torn i hut  ion  oi  this  ..cntr.ict  .  fne  .-.est  1  ochou t-1  ,;>t  i i  a  . 
modules  were  unavai laole  for  testing. 

Luring  the  first  quarter  of  1981,  testing  and  development  or.  e 
unit  level  basis  was  conducted  on  the  eight  jptical  translator  units  '  ' 
delivered  by  Singer  Keartott. 

Certain  problematic  conditions  existed  concerning  tne  'n  .  ompat- 
ibility  witn  tne  LAIS  multiplex  bus  .pec  i f i:..»ti  .n-  -f .  us  polar  *../  air; 
termination  in  particular.  After  these  pro  oleins  were  revolved,  worl  ef'urr 
continued  in  the  areas  of  hardware  debugging  and  unit  level  cnarac terizatiun 
onuer  a  combined  effort  involving  IRW  and  ArWAL,  U.  o  ' ..  that  naa  been  charac¬ 
terized  underwent  an  upgrading  process  whereby  the  1 ight  emitting  ciodet 
were  replaced  with  higr.  power,  nigh  reliability  /omnonerts.  T  •  ;  s  provided  i 
greater  signal  to  .noise  i.itiu  -mu .  thou  ret  u.i 1  ly ,  an  ...p?  .■  t 1  c-ft  e-t  ror  rat  »• 

Because  the  optical  star  coupler  was  i.ot  available  tor  r. pi  emeu 
f .  on ,  UTU  testing  was  conducted  on  a  partial  system  .evei  evaluation  only. 

■O',  results  of  01'.  testin'.-  are  due  umen » <.-d  in  iRW  puol  icat  ion  64nB-  j'  -O'. 

The  Fiber  optic  Evaluation  Software  is  trie  supf-ort  scHw-u  e  .  i- 
t  ■  oerfurm  system,  level  evaluation  o*  the  * : ter  op'.u  on.-.  anu  v*  ited 
iier  optic  Translator  units  ;  Oft.-  - I  he  •  io<"'  0:  t.i<:  Tv  a  i  m  -.o » r  wire 
lists  o*  s' a  functiona  i  software  •  oaf.1  us 


a.  Command  H'.neratiuri  bo  it  ware,  respond  tic  for 
control  o'  tne  Master  i’roce/ sor/Bolh  -or  -no 
transport  belay  Measurement , 

b.  Multiplex  boftwa*  e,  responsible  for  control  or  the 
Master  Process  or/ lit  Id  for  the  Data  Transfer  lest, 

c.  Remote  Software,  responsible  for  control  of  the 
Remote  Processor/ tii.  id  ( s )  for  all  tests, 

d.  Optical  Dynamic  Range  lest.  (OORT)  *1  Software,  respon¬ 
sible  for  control  of  the  Master  1  Processor/ In. ID  for 
the  Optical  Dynamic  Range  Te^t, 
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OORT  #2  Software,  responsible  for  control  of  the 
Master  #2  Processor/BCIU  for  the  Optical  Dynanic  Range 
Test,  and 


Word  Error 
control  of 
Error  Rate 


Rate  Test  (WERT)  Software,  responsible  for 
the  Master  Processor/BCIU  for  the  Word 
Test. 


>■ 


s'.  9  SOFJ_WARL 

l'.  1  Apjil  ica.iori  ^Software  A.-sessmert 

Both  .ne  J/3/1  and  the  J 73  versions  of  the  am*  1  icat  >o*i  so<  "wat  *.* 
were  assessed.  The  assessment  address*4.  the  f  •  llow:r-g: 

•  compliance  of  t tie  software  to  specifications 

•  performance  of  the  software 

•  adherence  of  the  coo<  to  standards 

•  usage  o'  tne  JcVi  'd  U"  •;  ik-r  and  lh>  [;[■}' 
hxecct : ve 

The  speci  t  i  cations  ,  trie  code,  the  roar  am  al  .critfr:  .  and  the  i. -piemen  tatior. 
were  evaluated.  Concentration  was  on  the  Jo'  u-enta ti on. and  it  was  evaluated 
against  strict  standards.  Therefore,  the  discrepancies  found  indicate  devia 
tions  fro--  the  standards  and  do  net  necessarily  •  >■*  V-  ?  jn  the  usabilit.  of 
the  product.  A  few  i nor  i nadegua: i os  exist  in  the  lopl >ca? i or,  software.  Oj 
these  are  not  serious  when  viewed  r.  the-  pe>  .-pec-ti  ve  of  c  >.  stiic  syste  . 

The  d  iscreuancie.  found  '■  ’•  '  no  do  i  *  ion  int  ■  u  to'  !e*v'n  • 

•  deviation  from  format  spec  i<  .<v  in  M !'  -  ’-"i-  i. 

MlL-slD-4'.'U 

•  t /oocira pn i ea  I  errors. 

•  inc  vi  * i  _ '  rut  or  (jci:  ’tali'’  ■  :  .  «• 

'  ne  dour  or.  tat  lot*  is  ,  ’lowt-ver ,  ■>vf  ei  iv°,  eovip  1  *  ’ 1  a  -  <’  n  .''at  * 

>'ru  Mens  *  >i.r>d  ;n  "ne  soft  *  iv*  im  !  ’  ■  <  •  w  ' i  *  o  : 

■  some  poor  1 y- commented  code 

•  some  1,1*0*’  program  mo  do  1  es 

•  *  ;  *  ;.  wa  ci(,e :  ,  *  w>  ver ,  f  i ?»f*  *  ,.!■•:  *  ‘  '  •  •  '  ■  •  •  ■ 

)■■[  ..  t 

T  tie  iJMSI.  f  o  f  •  w  re  w.v  thorough'  v  *  -e'-  .*-•  .  .•  e-.  <’  t  •  ..  *  ’ 

•  documentation  comm  eten"ss ,  acoirv*../,  and  u  -oh  * '  i  t. 

•  'acceptance  t”  :  <*■  u  ’. ts 

•  a  1  gor  i  tr  c  .•  a i'd  sat  i '-tying  regui  rwe  t  > 

•  v  )".wdiO  ;jsa!'i  'it/.  Pin  ’  U*  li  rar  i  1  i  t ,  ,  an*’  }•;'•  tabi  'it. 

•  (  veral!  desiun  and  us***  interlace 

t veral  1 ,  the  OMSS  software  and  docuriientation  was  judged  to  meet  or  exceed 
most  regu  ''emerts.  The  tol  lowing  profilers  found  are  minor  and  have  onl  y  a 
small  impact: 

•  i  :,rt  1  s  Manual  lawns,  kiwi  ground  i  n :  ema  t  ton 

•  Koi.nat  o'  Tables  ano  of  some  documents  is  confusing 

•  Interface  and  1 unction.!1  test  was  delayed  and  is  not 
ful  l.y  documented 

•  Si  •■no  cod  inn  does  not  cm  for*’  to  s‘ .rida-dx 


Ihe  UMS3  does  function  as  required.  The  evaluation  shows  this 
software  to  be  very  usable,  maintainable,  modifiable  and  portable. 

9.3  PMC  Assessment 

The  PMC  assessment  consists  of  the  following  five  sections: 

1.  Part  I  specification  review  and  assessment 

2.  User's  manual  review  and  assessment 

3.  PMC  system  capabilities  assessment 

4.  Assessment  of  PMC  capability  to  support  system 
testing 

5.  PMC  usability  assessment 

The  assessment  was  performed  by  a  five-member  team.  Upon  the  completion 
of  the  testing  an  assessment  report  was  written  to  the  DAIS  Document  Control 
Board  (DCB). 

The  PMC  assessment  resulted  in  the  following  recommendations: 

1.  Keep  the  current  system,  as  is,  for  possible  future 
use  in  the  AN/ AV K- 15  ITB/STS.  Most  of  the  basic 
functions  work  and  might  be  useful  for  future  debugging/ 
development.  In  particular,  the  team  feels  it  could  be 
useful  for  single  processor  module  interface  testing. 

Additional  development  efforts  to  improve  the  current 
system  are  not  recommended. 

2.  for  future  DAIS  developments,  do  not  use  the  current  PMC 
as  a  baseline.  The  concepts  and  some  of  the  functions 
may  be  useful . 

3.  for  future  PMC-tjpe  developments,  consider  small,  easy 
to  use,  stand-alone  tools  which  execute  fast  and  will 
satisfy  system  requirements.  Insure  that  needed  capa¬ 
bilities  are  provided.  Avoid  complex  functions  which 
may  not  be  used.  User  instructions  should  be  well 
documented  and  easy  to  follow. 

During  the  assessment  the  following  basic  problems  were 
discovered : 

1)  The  PMC  is  a  large  software  system.  It  contains  a  number  of 
features  that  are  complex  and  were  difficult  to  implement.  For  example, 
interface  with  J73/I  to  allow  debugging  at  the  HOC  level;  start/stop/restart/ 
of  the  system,  etc.  As  such,  it  is  difficult  to  use,  some  of  the  functions 
do  not  work,  some  produce  incorrect  results  and  the  system  crashes  under 
certain  conditions.  It  snould  be  noted  that  the  hardware,  such  as  the  BMu 
and  SCADUalso  impose  some  PMC  limiations.  Since  its  del i very/insta 1 lat ion , 
the  PMC  has  never  been  used  as  a  system  development/debugging  tool.  Users 
have  used  some  of  the  functions  that  the  PMC  performs,  but  have  not  done  so 
through  the  PMC,  i.e.  they  have  used  the  functions  in  a  manual  stand-alone 
mode . 


?.)  The  system  lacks  several  ca;w  i  1  i  t  u-s  needed  ter  ..si.-' 
deve  lopment/debaag  i  ng.  The  n.a  lot  eupu'd  i  it  ;(-•■  ••••tiled  are:  j. 
analyst  s;  Z)  bav  mi-i,  restoring  ’are  ane  »<•;!•  ti  *•'. ,  etc.  ;r>  '  rec.  • 

BLius,  and  -<ls;  and  3}  '.rating  uf  I'u..  traffic  cs-ir.ui  •  era '  y  v.it:  pn'. 
da  ta . 

3)  For  large  system  developments/testing,  the  PMC  lacks  •■uf' 
storage  for'  data  logging  and  does  not  contain  any  post-run  analysis  t  ap. 
ities.  Tor  a  long  mission  simulation  run,  large  amounts  of  da*"a  may  he 
be  co1  lotted,  then  a  program  wouid  be  needed  to  're.i’itf’  this  data, 
into  readable  form. 

4)  A  usable  PMt  "type  of  system  si.uold  be  an  integral  part  • 
sof  t wart*/ hardware  development/ tc-s t i mi  in  ,i  t«A I '  tvue  y'  laboratory  envi 
merit,  difficult  p»  obie-v.  wh  i  t  n  may  take  weeks  to  tire  pit.  re  sol  v-'d  q.„ 
with  proper  :'Vi,  tools. 

based  on  the  above  problems,  seven  1*  -orr.  leu'-m-  :  *r.  pr  < 
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I )  bevei  jl  sr.vl  1  ,  !<ss  complex,  software  tods,  performing  s* 
PMC  functions  are  essential  to  software/ hardware  development,  testing  ar 
ma  intenance. 
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MISSION  DEMONSTRATION 


The  overall  DAIS  objectives  are  to  (1)  reduce  unnecessary  develop¬ 
ment  proliferation,  (2)  improve  operational  efficiency  including  availability/ 
maintainability,  and  (3)  improve  flexibility  to  changes.  These  objectives 
must  be  achieved  without  sacrificing  the  mission  avionic  functional  capability 
attainable  with  conventionally  configured  complements  of  sensor  and  weapon 
subsystems.  The  satisfaction  of  these  objectives  and  the  requirements  for 
acceptable  system  functional  capability  have  been  illustrated  by  successfully 
operating  DAIS  under  simulated  mission  conditions.  Specifically,  the  mission 
demonstration  has  illustrated:  (1)  the  pilot  interface  with  Controls  and 
Displays  (C&D),  (2)  the  operation  of  the  processors,  mission  software  and 
multiplex  system  under  realistic  workload  conditions,  and  (3)  the  ability  of 
the  system  to  perform  weapon  delivery  and  navigation  functions. 

The  DAIS  demonstrations  were  performed  in  the  Integrated  Test  Bed 
facility.  The  purpose  of  this  facility  is  to  test  DAIS  mission  software  and 
core  element  hardware  under  real-time  conditions.  The  facility  provides  a 
'■eal-time  simulation  of  a  military  aircraft  performing  an  operational  mission. 
The  simulation  generates  the  interface  signals  so  that  the  DAIS  equipment  and 
nission  software  is  subjected  to  a  data  signal  environment  which  is  nearly 
identical  to  actual  flight. 

Simulation  software  was  developed  to  provide  real-time  simulation  of  a 
military  aircraft  in  an  operational  environment  including  the  aircraft  dynamics, 
the  aircraft  sensors  and  weapon  targets.  The  simulation  is  driven  from  the 
cockpit  by  an  operator  acting  as  a  "pilot".  This  simulated  cockpit  is  equipped 
with  the  DAIS  controls  and  displays  so  that  the  various  modes  of  a  mission  may 
be  "flown"  by  a  "pilot"  with  an  out-the-window  background  scene. 

Four  mission  demonstrations  were  originally  planned  to  satisfy  the 
overall  DAIS  objectives.  However,  as  the  DAIS  program  progressed  the  final 
two  demonstrations  were  deleted,  and  the  remaining  demonstrations  were  re¬ 
designed  and  redirected  to  satisfy  the  program  objectives  and  validate  new 
technological  capabilities  (MIL-STD-1553B  mul tiplex  architecture,  MIL-STD-1750 
processor  instruction  set  architecture,  and  MIL-STD-1 589B  (JOVIAL). 

10.1  Ba_s  e  l_i  ne  Demonstration  (Mission  a ) 

The  Mission  a  demonstration  was  successfully  performed  during 
September  197iJ  to  demonstrate  the  DAIS  system.  This  demonstration  was  the 
first  or  the  four  originally  scheduled  Close  Air  Support  (CAS)  demonstrations. 
This  initial  demonstration  included  functional  capabilities  such  as:  Inertial/ 
Baro-Damped  Navigation;  Command  Navigation,  TACAN  and  ILS  Steering,  MK82  Weapon 
Delivery  (with  weapon  scoring);  Stores  Management;  and  PREFLIGHT,  TAKEOFF /CL I MD , 
CRL'ISl  and  APPROAC.ti/LAND  checklists. 

The  simulation  was  flown  from  the  DAIS  cockpit  using  active  DAIS 
Controls/Displays  and  simulation  models  which  reside  on  the  DECsystem-10.  No 
real  sensors  were  used  in  the  demonstration.  The  avionic  system  consisted  of 
a  two-processor  DAIS  configuration  as  shown  in  Figure  56  and  Table  27.  All 
communication  between  the  DAIS  processors/Bus  Control  Interface  Units,  the  DAIS 
cockpit  and  the  simulation  models  was  accomplished  over  a  dual  redundant  MIL- 
STD-1553A  multiplex  bus  using  DAIS/1553A  system  protocol.  A  DAIS  remote 
terminal  was  used  to  interface  the  DAIS  cockpit  electronics  to  the  dual 
redundant  1553A  multiplex  bus. 
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MULTIPLEX  DATA  BUS 


TABLE  27.  MISSION  a  CONFIGURATION 


Weather: 
Target: 
Weapons: 
Threats : 


Night  -  Clear  (VFR) 
Fixed  Ground  Target 
MK-82  LDGP  Bombs 
None 


Simulated  Sensors:  INS 

Laser  Ranger 
Air  Data  Sensors 
Radar  A1 timiter 
ILS 
TACAN 

Core  Element  Hardware:  DAIS  Processors  (2):  Master  &  Remote  # 1 

BCIUs  (2) 

RTs  (2) 

Controls  and  Displays 


RT  (1) 

C&D  Mass  Memory 

VSD 

SCU 

HSD 

HUD 

MPD-1 

MPDG  (1) 

MPD-2 

DSMU 

IMFK 

AP 

DEK 

MMP 

Support  Facility:  ITB  Functional  Diagram  as  shown  in 

DA  100  102-1 


Functions:  Navigation  -  Inertial/Baro-Damped 

Steering  -  Command 
TACAN 
ILS 

Navigation  Update  -  Flyover 

HUD/Laser  Ranger 
FLIR/Laser  Ranger 

Acquisition/Cueinq  -  Pilot/HUD 

Pi lot/FLIR 

Target  or  (OAP)  Fix  -  HUD/Laser  Ranger 

FLIR/Laser  Ranger 

Weapon  Delivery  -  CCIP/Auto 
CCIP/Manual 


Stores  Management 
Communications  -  UHF 
Checkl ist 


-173- 


10 .  i  Upgraded  Mission  Demons  tr  a  lion  (Mission 

Using  the  Mission  u  demonstration  as  a  base!  hn.  for  develop  , 
several  features  were  added  whicn  led  to  the  Mission  .  demonstration.  1 h« • 
Mission  p  demonstration  was  the  second  and  ‘  inal  deirons  trat  ion  for  the  DAIS 
program.  It  was  actually  performed  four  times :  first,  to  demonstrate  the 
functional  enhancements  made  to  the  Mission  u  demonstration  baseline;  second, 
conversions  were  required  to  accommodate  the  MIL-STD- 1 553B  Multiplex  Systoi:  ; 
third,  the  software  was  re-targeted  to  run  on  the  AN/AIK-loA  ( MI L-bTD- 1 7L0 ' 
processor;  and  fourth,  the  software  was  converted  from  JOVIAL  to 

JOVIAL  (MIL-STD- 1539B) ) . 

The  Mission  C  demonstration  included  functional  capabilities  sou: 
as:  Command  Navigation,  Command  Heading,  Command  Altitude,  Command  Tract, 
TACAN,  and  ILS  Steering;  Dead  Reckoning,  and  TACAN  Area  Navigation;  MKM2 
Weapon  Delivery  (with  scoring);  Stores  Management;  and  PREFLIGHT,  TAKEOFF/ 
CLIMB,  CRUISE,  and  APPROACH/ LAND  checklists. 

As  with  the  Mission  a.  Mission  p  demonstration  was  "flown"  from,  the 
DAIS  cockpit  using  active  DAIS  Controls/Displays  and  the  simulation  models 
which  reside  on  the  DECsystem- 10.  No  real  sensors  were  used  in  the  demonstra¬ 
tion.  The  avionic  suite  for  Mission  6  consistec  of  a  three- processor  DAI:  con¬ 
figuration  as  shown  in  Figure  57  and  Table  28.  All  communication  between  the 
DAIS  processors,  the  DAIS  cockpit  and  the  simulation  models  was  a ccompl i she:; 
over  a  dual  redundant  MIL-STC-155 SB  multiplex  bus,  using  DAIS/ 2553b  system 
protocol.  A  DAIS  remote  terminal  was  used  to  interface  the  DAIS  cockpit 
electronics  to  the  duo’  redundant  1553B  multiple'  bus.  A1 though  each  cm  the 
Mission  ?  demonstrations  was  conducted  on  the  oasis  described  above,  each  was 
somewhat  different  in  the  technology  used.  Table  29  indicates  the  "user- 
transparent'  differences  in  the  three  Mission  3  demonstrations. 


FIGURE  57.  MISSION  6  CONFIGURATION 
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TABLE  28.  MISSION  B  CONFIGURATION  (Con't) 


Functions:  Navigation  -  Inertial/Baro-Oamped 

TACAN  Area  Navigation 
Dead  Reckoning 

Steering  -  Command  NAV 
Command  Track 
Command  Heading 
Command  Altitude 
TACAN 
ILS 

Navigation  Update  -  Flyover 

HUD/laser  Ranger 
FLIR/Laser  Ranger 

Acquisition/Cueing  -  Pilot/HUD 

Pi  1 ot/FLIR 

Target  or  (GAP)  Fix  -  HUD/Laser  Ranger 

FLIR/Laser  Ranger 

Weapon  Delivery  -  CCIP/Auto 
CCIP/Manual 

Stores  Management 
Communications  -  UHF 
Checklist 
Startup/Restart 
Systems 
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11.0  TECHNICAL  SUPPORT 

Throuynout  the  DAIS  program  a  high  degree  of  technical  interchange 
with  other  programs  and  other  Air  Force  organizations  was  maintained.  The 
most  significant  of  these  was  the  interaction/contribution  DAIS  made  to  the 
development  of  MlL-STD-15538,  MIL-STD-1750A  and  MIL-STD-1589B.  Other  tech¬ 
nical  support  supplied  by  DAIS  is  identified  in  the  following  paragraphs. 

11.1  Hot  Bench  Development  for  PAE 

DAIS  supported  the  development  of  the  Precision  Attack  Enhancement 
Program  at  Martin-Marietta  Corporation,  providing  numerous  software  packages 
including  Diagnostics  software  and  URT  software  for  checkout  and  use  on  the 
PAE  hot  bench.  DAIS  also  assisted  in  the  installation  of  several  versions 
of  the  Executive  and  supported  investigation  of  problems  related  to  the 
interface  of  these  software  packages  and  hardware  at  the  PAE  facility. 

11.2  Fault  Tolerant  Assessment  of  DAIS 

This  study  was  conducted  under  Air  Force  Contract  F33615-77-C-1232. 
DAIS  provided  technical  consultation  in  the  areas  of  reconfiguration,  monitor 
processor  plans  and  terminal  failure/recovery  operations.  Documentation  of 
the  System  Control  Procedures  and  core  element  hardware  specifications  were 
provided. 

11.3  Advanced  Avionics  Systems  for  Multi-Mission  Applications  (AASMA) 

This  study/implementation  effort  was  performed  under  Air  Force 
Contract  F33615-77-C-1252.  DAIS  provided  documentation  of  the  System  Control 
Procedures  and  Executive  software  as  well  as  consultation  on  technical  issues. 

A  version  of  the  DAIS  executive  was  used  as  the  starting  point  for  the  develop¬ 
ment  of  the  Single  Processor  Synchronous  Executive  (SPSE).  The  contractor 
reported  that  such  a  development/implementation  would  normally  have  been 
allocated  52  weeks  but  was  successfully  accomplished  in  3  weeks. 

11.4  Fiber  Optics  Bus  Receiver  Requirement 

This  study/implementation  was  performed  under  Air  Force  Contract 
F33615-78-C- 1561.  DAIS  supplied  technical  documentation  and  consultation 
on  multiplex  bus  and  RT  operations  and  supported  prototype  testing  in  the 
ITB. 

11.5  Remote  Link  Unit  Design 

This  study/implementation  was  performed  under  Air  Force  Contract 
F33615-78-C-1634.  DAIS  supplied  documentation  and  consultation  on  the  System 
Control  Procedures  and  multiplex  system  operation  and  supported  prototype 
testing  in  the  ITB. 


11.6  Fault  Tolerant  Computer  Network  Study 

This  study  is  being  conducted  under  Air  Force  Contract  F33615-79-C-1180. 
DAIS  has  supplied  documentation  and  consultation  on  the  startup/loader  operation, 
reconfiguration  and  difficulties  with  the  monitor  processor  concept. 


1 1 . 7  Mission  Management  Software  for  the  J3  - 1 2b  Avion  ics  Mode'  >i  1 1 ,  t'o- 
Hot  Bench 

This  design/development  is  being  conducted  under  Air  Foret  Contra'. 
F33615-30-C-0274 .  DAIS  supplied  technical  documentation  and  consultation  ;n 
the  system  control  procedures.  Executive  software,  models ,  simulation,  and 
other  support  software.  A  version  of  the  DAIS  executive  was  supplied  as  "it 
startin.'  point  for  this  development. 
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12.0 


CONCLUSIONS/RECOMMENDATIONS 


The  DAIS  program  successfully  demonstrated  the  concept  of  a  multi¬ 
processor  avionics  system  configuration  in  which  standard,  general  purpose, 
digital  processors,  programmed  in  a  standard  high  order  language,  communicate 
with  each  other  and  other  avionics  system  elements  via  a  standard,  dual  redun¬ 
dant,  multiplex  data  bus. 

More  than  just  a  concept,  the  DAIS  integrated  test  bed  represents  an 
actual  implementation  of  the  following  military  standards: 

•  MIL-STD-1553B 

•  MIL-STD-1750 

•  MIL-STD-158SB 

In  addition  DAIS  represents  a  comprehensive,  fully  tested,  mature  base¬ 
line  for  the  potential  development  of  new  standards  in  the  areas  of: 

•  Executive  Software 

•  Executive  to  Applications  Software  Interface 

•  System  Control  Procedures 

The  DAIS  architecture  is  a  proven  technology  which  can  and  "hould  be 
applied  to  real  aircraft  and  missions.  It  lacks  only  demonstration  in  a  real 
flight  environment  (vibration  and  acoustics,  EMI,  etc.)  The  Air  Force  should 
vigorously  pursue  the  infusion  of  this  technology  into  the  fleet. 

In  addition  to  the  above  overall  conclusions/recommendations»  a  number 
of  specific  items  are  covered  in  the  following  subsections. 

12.1  Core  Element  Hardware 


The  AN/AYK-15A  processors  represent  an  advance  in  avionics  technology. 
They  demonstrate  the  feasibility  of  embedding  a  bus  interface/controller  in  the 
processor  box  and  of  implementing  the  MIL-STD-1750  instruction  set  architecture. 
Of  major  importance  was  the  successful  dual  source  procurement  and  subsequent 
compatibility  demonstration.  There  is  little  doubt  the  AN/AYK-15A  processors 
will  find  widespread  application. 

The  Air  Force  should  continue  to  track  any  problems  or  variances  in 
operation  in  these  units  and  seek  resolution  of  any  which  threaten  compatibility 
The  specification  SA  421  205-1  should  be  actively  maintained  and  revised  as 
necessary. 


Evolutionary  enhancements  to  the  AN/AYK-15A  are  in  effect  being  scoped 
by  the  MIL-STD-1750A  working  groups.  The  area  that  should  receive  first  atten¬ 
tion  is  the  extended  memory  capability.  Other  areas,  not  covered  by  the  standard, 
which  should  be  investigated  as  an  extension  of  the  AN/AYK-15A  technology  are 
an  increased  intelligence  in  the  controller  to  handle  error  and  exception  pro¬ 
cessing  and  the  expansion  to  multiple  buses  to  support  future  hierarchical  bus 
architectures  and  the  like. 

The  DAIS  BCIU  proved  to  be  a  useful  step  in  the  development  of  the 
AN/AYK-15A  technology,  but  these  units  have  served  their  purpose  and  should  not 
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be  developed  further  .  In  lc  it.-  !r.(.  t  i  vr  <  AN/AYh  -  1  i  .  ..-v.nrs  ’  1  . 

car>  continue  to  pen  f  orm  nsef'a1  lato1  >'  r,  f'..nct  i'>  -  (,.  ,  .  ,•<  .  • 

•'or  example). 

The  OATS  RTs  demon st rated  that,  a  simile  unit  could  ’*  tee4 ace  >■  ■ 
variety  of  subsystems  and  siqrial  types.  However,  tne  cleat  ‘ "end  m  avic  i 
systems  is  toward  embedded  bus  interfaces  and  the  DAIS  HI',  cannot  be  expect*  ' 
to  find  much  applicability.  The  one  potential  application  would  seer  to  ft 
in  a  "clustering"  architecture  in  which  RTs  would  be  strut  eg  ire  1 ly  p’nced 
the  aircraft  geometry  and  interface  all  equipments  in  'tut  v  *  c  ini*..  A. »-  * 
from  this,  the  RT's  should  be  vi«*wed  •« ,  havin')  served  u  useful  » e  i  •  ,•  . 

meet  of  the  multiulex  technology  and  'tot  pursued  tut  ther. 

The  MIL-STD-1553B  multiplex  was  demonstrated  by  DAIS  to  be  an  ef*es*t. 
data  communications  technology.  Evolution  of  this  standard  is  to  be  expected 
and  the  DAIS  experier  ce  should  be  brought  to  bear  on  that  process.  As  idee*  'f 
in  the  conversion  discussion,  some  shortcomings  in  the  r  t  ami  a  rd  a  re  evide*  *.  '  *  ■■ 
example,  lac*  of  a  mechanism  to  clear'  the  vector  word).  At  the  same  t’*-*-  T 
should  be  recognized  that  when  MIL-STD-  1553B  deleted  the  mode  cone  "interrm,-*. 
module  error-  register"  DAIS  resorted  to  local  error-  handline  in  *he  RT  ..it1  '  r  ■ 
net  result  of  better  error  recovery  and  reduced  executive  software.  Thc-  'ess.-" 
learned  is  that  when  an  avionics  system  designer's  favorite  tec  ini  ue  seers 
incompatible  with  the  standard  it  may  well  be  that  the  s'  ci  hi  Id  i  ’  d  S  Li ! 1  [  1 1  1  0  S  ( •  f’ 
suggests  a  better  approach. 

The  DAIS  Controls  and  Displays  proved  to  be  an  elective,  Meni’.*  . 
pilot  interface.  The  advantages  of  multiple  purpos.  displays  a r»  evident  <•  ' 
there  is  no  doubt  they  will  persist  for  generations  of  avionics  system  u  ct  >.  . 
It  is  significant  that  in  formatting  displays  DAIS  found  it  necessary  to  oen“’-v 
graphic  representations  of  the  HSI,  the  FPM,  and  other  symbology.  The  human 
factors  considerations  must  not  be  overlooked,  and  the  graphic  representation  of 
earlier  generation  equipment  must  be  viewed  as  a  useful  general  purpose  ‘  •  i  o 

The  DAIS  system  mass  memory  was  actually  i  si  niafi  .  <i  ■  t  ut 
’"vise.  The  actual  bubble  memory  device  • -  •  c;  not  reacr  acre.-' able 
a  *.i.s  to  be  in  teg  i  a  fed  into  the  PI-  '*.  •  . Ibi'  i  ty  of  ’■."■■■  t  '  •  ’ 

.  :«>inor>  interfaced  via  the  multiplex  bus  was  demonstrated  but  neither  t>'v  ;•■  ■■ 
••ecord  formats  nor  the  interface  protocol  bear  any  ess^nt’a1  relation  to  th-  ,  ‘ 
memory  technology.  The  interface  protocol  was  driven  by  requirements  0*  cor - 
patibility  with  other  Air  Force  organizations.  The  system  mass  memory  should  be 
the  subject  of  further  investigation.  The  question  oT  intcrfacirg  via  the  bio; 

or  directly  to  processors  should  be  evaluated  in  light  of  advances  in  memo*', 

technology  (including  expanded  processor  memory)  and  the  Air  Force  should  rrnsv 
the  compatibility  requirements  on  the  interface  protocol.  A  record ~( rather  tna- 
word-)addressablo  interface  may  be  more  applicable  and  a  re-»ead  function  would 
be  useful . 

1?.3  DAIS  Software 

inc  uAIj  faster  and  Local  Executives  form  a  powerful,  general  purposi  . 
software  package  trial  can  be  the  basis  of  future  avionics  systems.  The  use  of 
the  executive  for  other  applications  has  already  been  demonstrated.  The  DAIS 
executive  was  the  baseline  for  the  Single  Processor  Synchronous  Executive  (SPSE) 
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developed  in  the  AASMA  program,  and  the  DAIS  executive  is  the  baseline  for  the 
current  KC-135  hot  bench  development  program.  In  the  former  case,  the  contrac¬ 
tor  reported  the  successful  generation  of  an  operable  executive  in  three  weeks 
time  whereas  normally  they  would  have  allocated  a  full  year  to  achieve  this 
important  first  milestone. 

The  Air  Force  should  continue  to  supply  the  DAIS  executive  as  the  base¬ 
line  for  new  developments  and  should  support  those  efforts  with  strong  technical 
assistance.  Moreover  the  Air  Force  should  follow  up  those  efforts,  soliciting 
feedback  on  problem  areas  and  specific  accomplishments. 

The  initial  implementation  of  the  DAIS  executive  was  excessively  large 
and  inefficient.  Improvements  have  been  made  continuously  as  the  system  matured 
from  one  demonstration  to  the  next.  The  combined  effect  of  better  software 
structuring,  the  removal  of  the  memory  boundary  constraints  in  the  AN/AYK-15A 
processor,  and  the  exploitation  of  the  single  word  instruction  format  of  MIL- 
S"D-1750  by  the  J73  compiler  resulted  in  an  overall  reduction  of  approximately 
30%.  One  specific  function,  minor  cycle  setup,  was  initially  a  very  complex 
function  which  was  measured  to  be  responsible  for  25%  overhead.  Restructuring 
bus  lists  and  reworking  this  function  reduced  that  figure  to  less  than  5%. 

This  progress  in  continuing.  The  final  executive  for  the  beta  demonstra¬ 
tion  was  about  4K  words  each  for  the  Master  and  Local.  With  technical  advice  from 
the  DAIS  program,  the  KC-135  hot  bench  development  has  brought  these  figures  down 
to  about  3K  and  2K  respectively  while  at  the  same  time  approaching  overhead  figures 
worthy  of  a  well  organized  assembly  language  executive.  The  lesson  learned  is 
that  oversized,  inefficient  software  is  a  consequence  of  specific  implementation 
techniques  and  not  due  to  the  use  of  a  higher  order  language.  An  efficient, 
reasonably  sized  executive  can  be  written  in  HOL. 

Two  implementation  approaches  were  identified  as  particularly  harmful 
to  the  DAIS  executive.  One  of  these  is  giving  strict,  pre-emptive  priority 
to  asynchronous  bus  operation.  The  other  was  the  adoption  of  a  virtual  memory 
approach  for  the  software  architecture.  The  asynchronous  message  handling  is 
discussed  more  fully  below,  but  briefly,  the  problem  is  that  suspending  and  re¬ 
storing  bus  operation  is  a  very  expensive  process  both  in  the  software  required 
to  accomplish  it  and  in  wasted  processor  time.  The  virtual  memory  approach  is  a 
useful  concept  for  software  development,  but  it  should  not  be  carried  over  into 
the  operational  system.  The  partitioning  of  related  tasks  to  different  processors 
results  in  additional  bus  traffic  and  even  if  it  is  not  done,  just  the  potential 
of  it  places  unnecessary  constraints  on  the  executive  software. 

In  practice,  task  partitioning  is  along  functional  lines,  keeping  related 
tasks  resident  in  the  same  processor  to  minimize  interprocessor  communication. 

The  executive  should  be  allowed  to  make  use  of  knowledge  of  the  system  partitioning. 
One  example  of  this  is  that  upon  a  mission  mode  change  the  Master  Sequencer  signals 
all  events  individually  as  if  the  tasks  were  resident  in  the  same  memory.  The 
event  handling  software  must  then  determine  what  tasks  are  not  resident  and 
generate  requests  for  asynchronous  messages  (one  per  event)  to  communicate  the 
signals.  Without  the  virtual  memory  constaint,  the  Master  processor  would  simply 
signal  the  mode  change  to  the  remote  processors.  As  noted  elsewhere,  the  virtual 
memory  approach  also  inhibits  reconfiguration. 


PA!  U  AC  w.s  or  if: '  r:  1 1  !  v  i  *  *  ;  O'Jtrructi  >  :  i-r!  •  (.•  'v- 

be  v*d  on  ••  or  r  o;  t  ■  >  •  i?  ..  Ion*  ’tM  to  «■  t.i  H«,  faiur.c'-  tv  ■ 

:  son  'o.iiiiri;  >n«i  neper.*  »e  a  bu'  *  >\  ‘f  i  i_  .  This  W-"  vwr  -K  r  or  :i !  ; s!  ed  ;-ji< 

P*'ima*  ily  tc  the  ’a*  t  the  do  t’Jril  part  i  tioni  ng  is  dtivt-n  by  a  nv  te* 

of  external  f  k  to»-r»  east  1/  encoded  *o  an  j  1  go»* i t .  1  Al  LI  >' C  it  not  >■  the- *;•'  s 

a  useful  support  tool  for  building  fy-.cutWe  tables.  The  Air  Core*.-  •  hould  ra;*  - 
tain  this  tool  are  console1'  upgrading  it  to  format  and  output  some  f  f  the  con¬ 
siderable  data  it  has  on  a  system/mission/conf igurati'  n.  .Without  much  difficu’tv 
PALE  FAC  cculd  be  made  to  generate  a  model  of  expected  system  performance  incluom 
a  timeline  of  bus  loading  across  mi  *.<:*•  .ycles,  peat  "rycessur  loads,  poter t i a '• 
systei  bottlenecks,  etc. 

The  DAIS  star  tup/ loader  war,  fully  demonstrated  to  accomplish  all  varia¬ 
tions  of  startup,  restart,  reload,  and  transient  recovery  tor  all  combinations 
of  processor  configurations.  It  is  a  complete  and  general  purpose  capability 
which  is  wholly  independent  of  the  DAIS  executive  software.  The  Air  Force  should 
make  this  technology  available  to  other  urograms  and  provide  technical  support  tn 
adept  if  to  applications  implementing  c  different  rase  memory  techno1 ogy  or  a 
different  processor  control  panel  approach.  Adaptation  will  also  be  required  if 
the  startup/loader  is  to  be  applied  to  ton  f  i  gut  a  t  i  -ms  of  more  than  four  processor-. 
None  of  these  adaptations  are  significant  and  apart  from  them  the  startup/loader 
is  capable  of  handling  any  configuration  of  processors  interconnected  via  a  VII- 
STD-1553B  multiplex  data  bus.  (Not  even  processor  compet ibi 1 i ty  i required; 
cnlv  the  standard  bus  interface.) 

12.3  DAIS  Suppor t  Ha rdwa re 

The  DAIS  complement  of  support  hardware  proved  to  be  an  effective  set  t  ‘ 
tools  for  the  checkout/'* teyration  of  the  DAIS  core  elements,  but.  for  the  most 
part  these  are  specific  to  the  ITB  configuration.  They  should  be  maintained 
and  assessed  for  applicability  to  future  laboratory  programs.  No  efforts  to  dis- 
Derse  this  techno!' oy  fr  other  programs  is  recommended. 

1 2 .  DA  I S  _%bbfi  n  t  So  ftwa  re 

The  tens i  sc  repertoire  o;  ;j,  corf  --rtware  ft. >el.v  c  1  c  •  f.- 
er.,q-'a:R  should  be  conscientiously  maintained  and  made  available  to  other  Air 
"ar.e  programs.  To  a  large  extent  this  has  already  been  accomplished,  but  • 

should  be  expended  to  sustain  a  widesoread  awareness  of  the  capability  and  avail¬ 
ability  of  the  DAIS  support  software.  A  presentation  or  two  at  appropriate 
national  conferences  would  seem  to  be  in  order. 

In  particular,  the  MIL-STD-I750A  acceptance  test  program  should  fine 
wide  appl icabi 1 i ty .  The  1750A  ATP  extensively  tests  the  instruction  set  and 
many  of  the  available  options,  thus  providing  a  useful  tool  for  verifying 
simulator  operation  or  detection  of  hardware  errors.  Possible  improvements  tor 
the  ATP  could  include  expanding  the  testing  field  to  cover  all  options  not 
currently  tested  and  combining  various  ins  true! ions  to  verify  actual  programming 
3  ituations. 

In  contrast,  the  performance  monitor  and  control  (PMC)  software, 
upon  careful  assessment  by  an  evaluation  team,  proved  unwie  ldy  and  unstable. 


The  PMC  software  evaluation  team  advised  that  software  not  be  changed, 
but  since  it  had  a  tendency  to  instability,  they  recommended  the  software  not 
be  used  for  a  baseline  for  future  software. 

12.5  DAIS  System  Control  Procedures 

The  DAIS  System  Control  Procedures  as  documented  in  MA  221  200-1  and 
SA  221  200  proved  to  be  an  effective  vehicle  for  identifying  and  resolving 
system-level  issues.  They  not  only  present  the  overall  system  operation 
(hardware/software/procedural)  but  also  illuminate  the  underlying  rationale. 

MA  221  200-1  documents  the  final  configuration  of  the  ITB  while  SA  221  200  is 
in  essence  a  system  designer's  guidebook  for  the  application  of  the  DAIS 
technology.  The  Air  Force  should  give  wide  distribution  to  these  documents 
to  aid  in  the  infusion  of  the  DAIS  technology  to  other  programs. 

Several  System  Control  Procedures  topics  deserve  separate  discussion, 
including  synchronous  operations,  asynchronous  operations,  error/failure 
handling  and  the  Monitor/Backup  concept. 

DAIS  demonstrated  that  effective  synchronous  communications  could  be 
accomplished  based  on  the  period  and  phase  concept.  Further,  by  adopting  the 
constraint  that  periods  should  be  a  power  of  two  and  adopting  the  convention 
of  transmitting  largest  period  data  first,  DAIS  was  able  to  define  a  static  bus 
list  requiring  only  that  the  BCM  be  started  at  the  correct  point  in  the  list. 

Thus  even  though  different  sets  of  synchronous  bus  operations  are  performed 
each  minor  cycle,  no  dynamic  bus  list  manipulation  is  required. 

DAIS  demonstrated  that  asynchronous  message  operations  are  strongly 
implementation-dependent.  DAIS  implemented  a  strict  priority  for  asynchronous 
operations  requiring  that  synchronous  operations  be  suspended  upon  the  recogni¬ 
tion  of  an  asynchronous  request  and  that  the  complete  decoding  of  the  request 
and  transfer  of  data  be  accomplished  before  resuming  the  synchronous  operation. 

This  proved  to  De  very  expensive  in  terms  of  the  amount  and  complexity  of  software 
required  and  it  resulted  in  processor  throughput  degradation.  It  also  was  the 
source  of  several  difficult- to-isolate  problems  of  a  hardware/software  interaction, 
timing  dependent,  variety.  While  alternate  procedures  were  defined,  they  were 
not  implemented  in  DAIS.  They  are  being  pursued  in  the  KC-135  hot  bench  develop¬ 
ment. 


Another  aspect  of  the  asynchronous  implementation  was  that  a  remote 
processor  advanced  its  transmission  queue  when  it  finished  sending  an  asynchronous 
message.  This  necessitated  a  special  re-transmission  procedure  when  errors  occurred. 
Interestingly  enough  the  conversion  to  MIL-STD-1553B  aided  the  solution  to  this 
problem.  The  deletion  of  the  mode  code  to  "reset  status  code  field"  forced  a 
rework  of  this  area  and  the  revised  control  procedures  withheld  the  transmission 
queue  update  until  the  reception  of  a  "synchronize  mode  code."  The  net  result  of 
this  modification  was  a  reduction  of  software  in  both  the  Master  and  local  execu¬ 
tive.  The  important  corollary  of  this  result  is  that  the  software  expediency 
of  performing  buffer  management  in  the  transmitter  at  the  completion  of  message 
transfer  actually  generates  additional  software  requirements  in  both  the  trans¬ 
mitter  and  master  controller. 


The  DAIS  experience  therefore  is  that  asynchronous  bus  operations  can 
have  a  severe  impact  on  size  and  performance.  This,  however,  is  not  a  property 


of  asynchronous  messages  b'it  rather  of  the  implementation  techr. j .juir. 
cien*" ,  fully  deterministic ,  asynchi  onous  implementation  is  possible. 

Message  error  handling  and  retry  is  an  important  related  area  that 
the  System  Control  Procedures  must  deal  with.  At  one  point  in  the  DAIS  procra- , 
when  the  control  procedures  applied  error  considerations  to  all  message  types 
and  combinations  of  transmitters  and  receivers.it  became  necessary  to  define 
seven  separate  classes  of  message  retry.  By  the  time  of  the  final  DAIS  demonstra¬ 
tion  this  had  been  reduced  to  two  types  of  retry  plus  special  handling  for  the 
system  mass  memory. 

The  careful  retry  procedure  was  introduced  to  handle  the  situation  o* 
a  device  of  subsystem  which  would  function  improperly  if  sent  data  twice.  An 
early  DAIS  configuration  had  an  inertial  measurement  unit  (1MU)  which  operated 
in  this  fashion.  The  procedure  to  handle  this  type  of  device  is  to  perform  a 
"last  command"  mode  code  operation  to  first  confirm  that  the  device  received  the 
command  work  and  then  a  "transmit  status"  to  confirm  the  device  did  indeed  detect 
an  error  prior  to  repeating  the  message.  And,  of  course,  proper  operation 
requires  this  be  performed  immediately,  before  resuming  normal  bus  operations. 

MI L-STD- 1553B  removed  the  need  for  a  separate  transmit  status  operation,  but  the 
last  command  sequence  remains  an  awkward  procedure  with  undesirable  software  and 
performance  impacts.  The  Air  force  should  eliminate  this  requirement.  Subsystem 
procurement  specifications  should  include  the  requirement  that  the  subsystem  shall 
continue  to  function  properly  when  intermittently  sent  repeated  data.  The  sub¬ 
system  should  similarly  be  tolerant  of  occasional  brief  lapses  in  the  data  flow. 
The  /ir  Force  should  place  the  same  requirements  on  application  software  and 
should  include  data  repeat  and  data  lapse  tests  in  acceptance  test  programs  for 
application  software  and  subsystems. 

Another  type  of  message  that  represents  a  severe  difficulty  for  the 
system  control  procedures  is  the  "critical  message."  This  is  a  message  which 
must  succeed  for  proper  operation.  If  that  is  indeed  the  requirement,  the 
control  procedures  have  no  choice  except  to  terminate  in  endless  retries, 
device  failure,  or  system  failure.  The  Air  force  should  endeavor  to  eliminate 
cr’i-’cai  messages"  wnenever  possible. 

The  Moni  tor  /Backup  operation  is  an  area  in  which  DAIS  did  not  accompli-.  * 
its  original  objective.  The  startup/loader  provides  a  complete  reconfigurati.-1 
capability  and  (for  certain  systems  and  missions)  this  is  sufficient  to  accomplish 
the  Monitor/Backup  function,  but  DAIS  did  not  succeed  in  solving  the  general 
case  problem.  The  Monitor/Backup  concept  is  one  in  which  a  spare  processor,  the 
Monitor,  is  capable  of  detecting  a  failure  of  the  Master  and  then  of  assuminq 
the  functions  cf  the  Master  to  maintain  system  operation.  DAIS  defined  and 
demonstrated  the  mechanism  for  the  monitor  to  quickly  and  reliably  detect  a 
master  failure  and  to  take  control  of  the  system.  The  stumbling  block  is  in  the 
definition  of  the  contents  of  the  monitor.  The  nominal  definition  of  a  duplicate 
of  the  master  leaves  unaddressed  the  question  of  how  the  monitor  obtains  adequate 
data  on  the  state  cf  the  system  to  actually  perform  the  master  function.  The 
approach  of  configuring  the  Monitor  as  a  remote  during  normal  operations  in 
itder  tiiat  the  master  can  send  him  the  required  data  has  several  flaws.  It  adds 
3of tware  requirements  on  the  master,  negates  the  concept  of  the  duplicate  master 
and  creates  a  spectrui"  of  failure  cases  for  the  monitor  to  deal  wth.  This 
approach  must  also  answer  the  difficult  philosophical  and  practical  question  of 
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how  can  the  monitor  reliably  begin  system  operation  based  on  data  received 
from  a  failing  master. 


Another  aspect  of  the  Monitor/Backup  problem  is  the  monitor  assump¬ 
tion  of  the  role  of  a  remote  processor.  A  reload  is  required  in  this  case  and 
it  is  desirable  for  the  balance  of  the  system  to  maintain  a  degraded  mode  of 
operation  while  this  is  taking  place.  The  virtual  memory  architecture  of  the 
software,  however,  permits  each  remote  processor  to  depend  on  every  other  for 
correct,  continued  operation.  In  principle,  then,  the  degraded  mode  of  opera¬ 
tion  is  not  possible.  The  system  operation  would  have  to  stop  while  the  monitor 
was  reloaded  and  reinitialized  to  perform  the  remote  function.  This  approach 
is  within  the  scope  of  the  current  DAIS  technology  but  it  was  not  implemented 
since  the  startup/loader  already  accomplishes  the  equivalent  end  result  and  is 
a  more  general  solution  to  the  restart  problem. 

Thus,  DAIS  has  solved  the  error  detection/rapid  failure  portion  of 
the  Monitor/Backup  problem,  but  lacks  a  definition  of  the  Monitor  content,  the 
protocol  to  update  it  with  current  data,  and  the  ability  to  continue  operation 
following  a  remote  failure.  The  Air  Force  should  continue  to  address  the 
difficult  question  of  the  Monitor/Backup  technology.  The  most  promising  ave¬ 
nues  appear  to  be  in  first  controlling  the  software  parti oning  to  remove  the 
interdependency  of  remote  processors  and  secondly  of  expanding  the  bus  controller 
capability  to  include  an  operational  mode  which  is  truly  a  monitor,  i.e.  one 
in  which  the  required  system  state  data  may  be  obtained  without  perturbing  the 
normal  system  operation  (in  which  case  the  duplicate  master  approach  is  feasible). 

These  issues  must  be  addressed  in  future  programs,  but  always  in 
the  context  of  the  system  control  procedures  so  that  all  pertinent  considerations 
can  be  brought  to  bear.  It  is  recommended  the  Air  Force  give  a  high  priority 
to  this  area  of  advanced  avionics  technology. 
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